Summit 2023 Notes

This page documents the notes that were taken during the 7th OpenPGP Email Summit which took place 2023-05-26/27.

Contents

  1. Summit 2023 Notes
    1. Plenary talks
      1. Post Quantum - Aron
      2. Header Protection for Cryptographically Protected E-Mail - dkg
      3. WKD and Abuse Reports
      4. Learning from WKD at scale - Bart
    2. Workshops
      1. V4 - V6 transition
      2. Signature Failures
      3. PQC
      4. Shared Library API
      5. OpenPGP CA - Run by Aron
      6. Authentication Certificate - Identity
      7. WKD / Lookup privacy
      8. Historical email archive
      9. Intended Recipient Subpacket
      10. GnuPG interoperability
      11. Action items
      12. Next summit

Plenary talks

Post Quantum - Aron

Header Protection for Cryptographically Protected E-Mail - dkg

WKD and Abuse Reports

Learning from WKD at scale - Bart

Workshops

V4 - V6 transition

dkg: want to make a V6 key ASAP, ensure it's available to who can understand it. What are the problems with this key distribution?

Signature Failures

how should we display broken signatures?

Some kinds of brokenness?

Are some kinds of signatures work showing vs. others?

Baseline: keep it simple.  treat a broken signature the same as no signature.

Where the user can reasonably do something about it, maybe we want to prompt the user

Is it different for cleartext vs. encrypted messages?

what can we learn from web browsers?  from Signal?  From OMEMO?

How should we indicate encrypted-only messages (those that have no valid signature)?

Can we make an HSTS-style signal to so that the sender can trigger a warning on unsigned messages?

These signals might break for messages relayed through mailing lists.  SRS (sender rewriting scheme) would make it so that the signal doesn't apply.

how can we build a consensus that warnings should not be shown?

Re "Broken signature is no signature" does not work for Proton, where they show a warning about a message that appears to be signed but they don't have the key so it cannot be validated. When they fetch the key and the signature is broken, suddenly the message displays as not signed?

PQC

(note taker: Falko)

Justus: Who is pushing for SPHINCS+?

Aron: Phil Zimmerman also pushing for SPHINCS+

Long term security solution for signatures. PGP usually not used for authentication.

Daniel: Is BSI interested in SPHINCS+ in OpenPGP

Falko: Will probably use it in German gourenment PKI. For OpenPGP probably also interesting for them for other purposes.

Aron: (shows the list with algorithm requirements in current draft) SPHINCS+ is adding the most implementation complexity. "MAY" for SPHINCS+ and not "SHOULD" is something we could discuss.

Falko: comparison with numbers from submission

Aron: We have similar numbers than the reference implementations

Justus: I am more concerned with verification and that seems to be not that bad.

Aron: thought about dropping the small variant

Falko: shouldn't be done because application contexts have different requirements

Aron: Algorithm matching L3 PQC with 384 (current draft) or 512 bit curves

Falko: current combination comes from LAMPS and doesn't address the long term security of the traditional algorithm

Aron: 384 bit curves is what CNSA standard prescibes, but we don't have to necessarily follow it

Aron: Usually people want either the fastest or the more secure version, could drop the intermediate parameters

Daniel: makes most sense to pair the algorithms according to their security levels, as otherwise it is not a fallback to the same security level

Aron: X25519 and X448 are an exception, they are already paired in this way

Nickolay: What is contribution to the signing time in the EC + Dilithium?

Aron: It is about 50% percent overhead, typically curves slower than

...: Maturity of the PQC implementation regarding side channel?

Aron: We are using cloudflare implementation for Dilithium (?). Kyber reference implementation is constant time and doesn't have fault attack protection.

Justus: I am interested in a small algorithm catalogue as we will not implement them ourselves but have to rely on crypto libraries. Nettle's implementation of OCB took a long time.

Falko: This set is the NIST selection which schemes will be mostly implemented in libraries.

Aron: SPHINCS+ is going to be asked for by many parties. Will be used for packet signing and Sequoia will be used for that.

Falko: Botan will receive all the algorithms in the draft

Justus: But not yet in Botan's FFI interface. There is little things that need to be added.

Aron: KMAC required some low level tweaking. We could replace it with SHA-3. In EC KDF there is an ambiguity in the encoding used with SHA-3. But the new construction could be adopted to avoid collisions with the one just mentioned.

Justus: now I am fine with KMAC since nettle already has cSHAKE already. Would be good if nettle will offer KMAC in the future.

Aron: Shall we move on to the topic of interop testing?

(no objections)

Aron: In the beginning we could just exchange test vectors. But in the long run the SOP test and interop testing service would be a good solution.

Daniel: Since it is not standardized yet Justus could  handle it like v6 with a new page

Justus: One question is how we get the implementation artifacts. Currently we are using docker images. It is a bit slower, though.

Aron: The idea would be to create a docker container that with a tag for the draft version.

Daniel: that would also allow to put a config file on a config file in github repo where they can add their implementation which is then automatically fetched.

Justus: It wouldn't necessarily have to be me managing this. Not to happy with this since I run everything on my machine. Would be nicer to have a server for this.

Daniel: We have the OpenPGP.org domain. We could make subdomain tests.openpgp.org for this purpose. But it is very utopic.

Aron: The idea with the docker images is to take the effort from you regarding updates to the implementations. Also I remember we had deprecated SHA-1 in Go-OpenPGP and the interop test suite did show this only about 7 months later. So the manual updating isn't optimal.

Aron: Another questions is binding the PQC keys to the packet versions. So far the spec says you must produce v6 keys and must use v6 PKESK. Yesterday Falko and I talked about this and we have the options:

1. allow everything: PQC is just new algorithms

2. bind them to the newer keys but also allow v3 PKESK. Then we could send encrypted messages also to mixed recipients.

3. leave it as now (bind to v6 strongly)

1st is interop advantage with GnuPG. But we also have a salt in v6 signatures. Salt must be prepended to message in order to be useful. There is some security reduction.

Falko: Security reduction due to missing salt is generally for v4. Should view the PQC and v6 improvements separate to enable it for the greatest set of users.

Aron: I am happy for relaxing the requirements for encryption, but not for signatures. Do we want to repeat what was done with X25519.

Justus: if the goal is to be interopable with GnuPG this might not work if GnuPG chokes on the unknown algo version even if not own fingerprint in packet.

Aron: Do we want to have the binding of PQC to key version? Encryption is more urgent so should we allow it with v4 keys? For signatures maybe wait for a few years.

Justus: An argument could be made for unbinding it from the packet version like X25519. That is not even the question. The question is sending a v3 PKESK when one recipient has only v4. Or do we want to allow v4 kyber keys?

Aron: I am OK with the second, but not with the first (regarding enumeration above)

Falko: For encryption it is urgent to enable it so v4 keys should be allowed to have a failproof solution.

Aron: That is a fair point.

Shared Library API

(note taker: Patrick)

"C" style --> .so / .dll interface

Sugegestion: use libabc README (Linux Kernel)

Base it on builder operations (e.g. expected timeframe, keys, etc)

Opaque Objects:

Example:

1 certs x

2 op\_verify y

3 verify\_with\_cert(x, y)

4 ...

5 verification\_result = verify\_go (y, data, sig)

--> what happens if x is modified between 1 and 5 (e.g. verify\_add\_cert(x, a))

Questions:

Addiditional Considerations

OpenPGP CA - Run by Aron

Authentication Certificate - Identity

What is Authentication? what are its problems? 

Zooko's triangle  

                                    Secure  
                                         ^  
                           /                        \\ Fingerprint  
               /                                                \\  
     |---------------------------------------------------|  

Human-usable     Email                   Distributed

There is a difference between global and local identifiers:

Organizations have different scopes, depending on their "interest distance" to the subject.

On a scale from local to global, we can organize organizations like this:

Local \[ 1st party Orgs | 3rd party Orgs | Special Interest Authorities | WebPKI \] Global

If I want to check the signature on a software package, I need to do: 

Package  
|  Download  
v  
Signature  
|  Math  
v  
Cert  
|  Authentication  
v  
Identity  
|  Correct or expected identity  
v  
User

Key-Transparency BoF at IETF

We discussed different key discovery processes in KMail/Kleopatra and Proton.

Different threat-levels, some messages are "just" embarassing if they get leaked, while others might bring me to jail / threaten my life.

In Protons new API they differentiate between keys and unverified keys, depending on the source (WKD/Internal/...)

In Sequoia: WoT is powerful mechanism, ideally we just pour all our data into WoT and let the WoT engine figure out the rest.

In Sq, WoT is a maximum-flow network with edges having different weights, calculating how much authenticity flows to the target.

WKD / Lookup privacy

facilitators: Kai & Bart

note-taker: dkg

Lookup privacy: queries to keyservers or WKD yield information about who is interested in which address

How can clients (like thunderbird) refresh keys automatically without leaking information about who is interested in which clients?

OHAI (oblivious HTTP) work is ongoing at the IETF.  clients should be able to use OHAI with a cooperating proxy to hide thier queries from a server.

some systems might work for one but not the other.

Why not have the keyserver report updates generally to avoid the client?  Bernd -- could use bloom filter

Justus: Keys.OpenPGP.org already has a specification for how to publish updated keys, but it is not yet being published by the keyserver.  [https://gitlab.com/keys.openpgp.org/keystore-updates](https://gitlab.com/keys.openpgp.org/keystore-updates)

Justus: classic approach is parcimonie -- update one cert from your keyring at a time, randomly, running over Tor.  Gives you regular updates, based on how many keys you have and how frequently you're willing to update.

Detect Tor if it's available.

Justus: if people use the octopus plugin for Thunderbird, this is already happening.

Andrew: could a WKD server return all keys related to a prefix (based on the hashed e-mail address)?

dkg: could WKD servers publish a "recently-updated" keys?

Bart: you don't need a VPN, you just need a TCP proxy -- might be easier to go through a corporate firewall

dkg: WKD (and any keyserver) traffic sizes are visible.  traffic analysis lets the network operator see who is being asked about, despite the TLS connection.  We need a standard padding policy for queries and responses.

Justus: koo can look at the actual distribution of key sizes and determine an optimal padding policy

Kai: what about blockchain or CT-style keys?

Daniel Huigens: key transparency work (at IETF, focused on MLS).  there's a tradeoff about enumeration, though.

Kai: should a public log have OpenPGP certificates without User IDs?  that lets you learn subkeys and revocations

Bart: What else needs to happen with WKD?

Andrew: there are so many changes here that it looks like you're talking about WKDv2

Proposed changes from Bart:

Kai: do we still want WKD?  or should we put more attention on keyservers?

Andrew: WKD obeys the principles of e-mail in that it is federated/distributed.  we should keep it, and the keyservers aren't sufficient.  Keyservers should be a fallback method

dkg: how are we going to evolve away from an earlier WKD spec?  do we need a query parameter?  do we need a way to announce that we don't support v2 (e.g. for migration to a future version?)

Historical email archive

Daniel H, Andrew

Notes: Aron

Decryption of emails encrypted to old keys

Session key cache: Having a cache would speed up the decryption of encrypted keys, but would not solve the re-encryption problem, because that deleting the PKESK and keeping the cache only will create problems when user change devices.

Re-encryption: see "Re-encryption of email encrypted emails to obsolete encryption algorithms"

Full-text cache: Download, decrypt, delete from server. This would resolve also (3)

Search across inbox/archive

A cache would improve search performance, but not provide the desired results.

Searchable encryption leaks information due to access patterns, server side search is not really possible. You need to have a local index to have a privacy compliant system.

Re-encryption of email encrypted emails to obsolete encryption algorithms

Another solution is to have a "Public" key algorithm that is a symmetric algorithm that would create symmetric PKESKs. This could be used to replace the algorithm ID in the PKESK. (Throw away old PKESK and create a new symmetric PKESK)

Neil: Why not use the SKESK?

Daniel: The SKESK is suitable for passwords, not for keys.

Andrew: Why not define a different S2K?

Daniel: The PKESK has already the right semantic, KeyIDs, Algorithm IDs, ... It's just lacking the right name. We could rename PKESK to "Key-Encrypted SK" and "Password-Encrypted SK"

Re-encryption Solves? Symmetric Asymmetric
Legacy algorithm Yes Yes
Old keys / rollover Yes Yes
Decryption performance Yes No

Solutions for Decryption (performance?):

Solutions for Legacy Algorithms:

Record that a signature made by obsolete algorithm was verified when it was good (Also consider that hard revocations may have happened, backdated)

The symmetric "public" key algorithm could be also used for notarization as a signing algorithm to notarize signatures.

Not to break the "Intended recipients" packet you should record the verification status when re-encrypting.

Intended Recipient Subpacket

abbreviation: IRS

DKG: the IRS is a feature where you make a signature that contains a sub packet that has a fingerprint of the public key that the message was intended for.

The problem this feature tries to address:

Syntax: for each recipient a new sub packet with the primary fingerprint

BCC: you do not use the sub packet to avoid putting information into the message about the recipient

Concern: sending a cleartext message, no IRS surreptitious (sneaky) forwarding

IRS cannot be removed from the signature because it is in a hashed sub packet

Tombstone (empty) IRS signals the message was not encrypted.

What will you do with an encrypted and signed email without IRS?

Is signature without IRS valid if it is part of a message with a SESK?

Related to cached signature validation

Different states.

Reevaluate if IRS is the right solution for the problem.

Initially this problem is known since 2001 in the area of mailing lists (Schleuder).

Encrypted headers could are a solution for this issue.

Might be inconsistencies between protected headers and IRS

Bart: the more we talk about it, the more I think IRS should not be continued for email

Should this solution exits on the OpenPGP layer? Difficult to explain to the user what is happening here.

Discussion of protected headers solves the problem completely or only partly.

Is there a real world problem that cannot be solved outside of OpenPGP?

Does the surreptitiously forwarded email problem be solved by OpenPGP?

If not, then a simplification would be to remove IRS.

Kai: file that is too big for email and instead you share a link.

Bart: authentication in this example is if the link is the correct link. They could replace the downloaded file with other file that is also signed with the key of the sender.

Final words from DKG: frustrating session, topic is more unclear than before

Wrapup (DKG): Not clear what signals the IRS gives in a message. In some cases the IRS would render a signature as invalid. In other cases if makes a statement about the confidentiality of a message. For many things the IRS tries to do it doesn’t make it right. We would extend the IRS spec with a tombstone packet that can be used for cleartext signed messages. There is an intersection between protected headers and IRS. One solution could be: for email context you ignore the IRS, but that has also consequences for SOP, because it means you get different outcomes for different contexts.

GnuPG interoperability

Kai, DKG

Notes: Andrew

kai: would prefer if thunderbird was compatible with everyone

what do applications/consumers do?

bart: you can continue to use v4, or we can try to encrypt to both v5 and v6; may be technically possible

aron: also consider how to handle signatures

Technical issues:

bart: in immediate future v4,v5,v6 will have to coexist

aron: will future v6 work e.g. pqc be backported to v5? We may find further points of divergence

dkg: most technical issues above also apply regardless of v5 existence

daniel h: we should encourage everyone to implement both v5 and v6, but issues will remain

dkg: we have only one way to encrypt to multiple recipients using multiple versions, and that is use v4

bart: best thing for openpgp community in long term is for v6 to succeed. Too much choice has historically been a problem

aron: as proton we will disallow users to upload/create their own v5 keys but may support third-party v5 keys

nickolay: Best to understand everything but create according to your own policy

kai: I see thunderbird as a power tool, and its users want to be compatible

bernd: thunderbird can allow power users to choose

bart: defaults are powerful, you can set v6 as default. We are supporting v5 in e.g. openpgpjs, but we still prefer v6

kai: Changing our default to v5 is off table, but am also reluctant to change default to v6 because it breaks compatibility

dkg: we are going to have a conflict between v4 and v6 because v4 is more compatible and we will be pressured to staying with it

aron: we already migrated our users to elliptic curve keys and it was not that bad

falko: how is rollout planned anyway? What is strategy?

dkg: I expect rollout to start with signalling on existing v4 keys: sha3, seipd2. Nerds will then generate v6 and use in parallel with v4. Finally general rollout of v6 by default.

aron: thunderbird does not have to lead this process, can let others with less compatibility concerns lead rollout

falko: can allow optional use for those who wish to experiment

nickolay: what is the standard implementation for apple mail?

andrew: most common is macgpgtools, which is downstream of gnupg

bart: am worried that an extended period of v5 compatibility will just prolong the issues

daniel h: my proposal for everyone to implement everything is designed to encourage future reconciliation

aron: we could bind pqc to v6, that will encourage people to migrate, to avoid having to reimplement

neil: it is possible that gnupg users and v6 users already form loosely-connected groups and therefore can't influence each other's choices. German government mandates a full stack that uses GPGOL which is therefore independent of what other implementations choose.

bart: I don't want to force gnupg to do anything, I'm happy for coexistence so long as those who wish to move on, can

nickolay: are there known security issues with v5?

dkg: there are some, but arguable that these don't affect pqc since they only allow forging of v3 sigs. Easy fix is rejecting v3 signatures.

daniel h: in email context rejecting v3 should be possible, package distribution can be treated separately

aron: there is an issue with sphincs wire format lacking salt in v5

justus: most implementations are not sufficiently forward compatible with unknown versions, algorithms etc. Please check the interop test suite and fix interop failures.

nickolay: can we ask v5 implementers to reject v3?

dkg: this is ineffective because the creator of the v5 signature can't be sure the recipient is rejecting v3

Action items

Next summit

Interim

Full

OpenPGPEmailSummit202305Notes (last edited 2023-05-29 22:13:09 by KaiEngert)