Session Summary OpenPGP Email Summit 2018

(see OpenPGPEmailSummit201810)

Session 1: new standard for OpenPGP: TLS 1.3, RFC4880bis - Phil Zimmermann

Session 2: SKS keyserver - Kristian Fiskerstrand

low number of operators

mapping from fingerprint to uid still useful

openpgp should not use 509's centralized model

did updates for new key materials at some point

can't do large changes for time and ocaml knowledge contraints

K: Right, that's how it is. Can't use letsencrypt because custom cert is used today

pgp global directory: checked with confirmation mail

pleasure to use: singular mapping, no bogus keys wouldn't it be nicer to li to live in a world where we don't have so much crap on the keyservers?

validation and federation impossible to combine

it's called, but historically we accepted other implemenations need to decide on minimum requirements definitely right approach, instead of doing large rewrites on sks

totally differnet set of problems if we're only implementing a revocation server

you can reuse all this stuff for free like Certificate Transparency

Session 1: Autocrypt level 2

which features do we want?

Organizational process

Can we do "level 1 compliant" badging?

How can we evaluate that a client isn't level 1 compatible?

potentially try to launch level 2 work before IFF 2019


next up

next steps

Session 2: MUA state sync

Session 3: Counter MITM

[Unstructured follow-up to the Counter-MITM paper presentation in the morning.]

Q: What kind of in-person key verification mechanisms did you envision? QR? etc?

A: Paper is agnostic, some mechanism for transmitting bootstrap data, fingerprint + 2 secrets. One (invite token) secret to authenticate initial message, trigger response with PGP key. Response triggers encrypted message containing second token, proving verification completed, also including fingerprint of initator. (Discussion, whiteboard)

Q: What do "system messages" look like?

A: First message is cleartext, the rest encrypted. Using headers inside the encrypted part to transmit data. Useful for other MUAs to know, so as to be able to suppress these messages. Very similar to DSNs, but modified so as not to be recognized as such, so as not to trigger messages back.

Q: Discussion about time-outs in the verification flow...?

A: Currently unlimited, policy needs to be defined.

Q: Are separate keys stored for different contexts, groups/vs. 1:1?

A: Yes, the groups use the latest verified key, Autocrypt just uses the latest received key. (discussion about keys)

Q: What about key change notifications like Signal/WhatsApp?

A: (discussion)

Q: What does it mean if keys change?

A: Delta is very simple, if any bit of the key changes, it's a new key.

Session 3: Webmail / Autocrypt

Session 4 - Multiple Key Discovery methods

Session about how MUA's that support multiple key discovery methods handle them and how to handle different answers Collection of existing key discovery methods (on the right is how you search it): autocrypt - email WKD - email SKS pool - email | keyid | fpr Mailvelope keyserver - email | keyid | fpr LDAP - email | keyid | fpr DNS - email garbage pile - email | keyid | fpr keybase etc. local override (e.g. local signatures on manually imported keys or the addressbook) Garbage pile: New keyserver by Kai and PEP: only search for full user id's and validates E-Mail addresses. Only after validation the key is searchable Allows for removal We scope the discussion to lookup by email address. What is the confidence in the discovery methods. WKD: In GpgOL and protonmail and Enigmal: Keys from WKD are used directly for automatic encryption without user interaction Policy overrides e.g. local signatures are override that Enigmal and GnuPG have a list in an order where they look for keys. Concern is that Meta data leaking key sources should not always be tried. Local sources are preferabble and prefered. Meta data leakage concerns, each key discovery source has different meta data leakage DNS is especially problematic WKD only leaks the domain

Ranking and collision handling: There could be the state that different services report different keys WKD can have multiple keys in a response There was discussion about this that it might be a bad idea and should be changed in the future. Mailvelope keyserver and garbage pile both only return one result.

Strategies when multiple keys are found: Ranking - by validity or other criteria like last created subkey Encrypt to all of them - has the advantage that there is the least danger that the recipient can't decrypt the message Escalate the problem to the user

For lookup Start with no meta data leakage and little latency

Sidetrack WKD: A provider can have mutliple canonicalisation methods esp. with Unicode in the local part WKD does not really has a policy for this except something simple like lowercasing.

There should be a canonicalisation policy for WKD.

Session 4 - Signature taking over time

DKG: When you recevie a message and it is signed, we have some idea what that means, and some ideas about how it is presented to the user. When you look at messages in your archive from a year ago, that are signed, you might feel differently. Has the key expired since? Has the key been revoked since then? (or the subkey) .. lost the keys? Or the other way around, you now have a key and can verify old stuff. It's not clear what a signature means over time, with a store and forward protocol like e-mail.

Most messaging protocols don't have his, they don't have per message non-repudiating signatures.

1. What are the ways that a valid signature effects my MUA?

2. What are the ways that an invalid signature effects my MUA?

3. If I'm looking at old messages, and status now is different, does that effect what my MUA is going to do?


OpenPGP.js: Treats expiration and revocation as different. When a signature is verified, key validity is derived from signature time.

DKG: The message has many dates, which is used?

ProtonMail: Uses Received headers. Unless it is very different from the when the message was entered into the database.

GnuPG: uses timestamp on the signature itself, if the key was not expired, it is considered valid. Otherwise invalid. If it's signed before key creation time, there's a warning but considered valid. If revoked, if the revocation is due to compromise it is always invalid, if superceded, revocation time wins. Ignores all the e-mail specific data.

Usually date related failures are caused by bad clocks.


What does your MUA do differently if a signature is valid?

Outlook: Shows a green bar if the signature is valid when it is displayed. Never show any warnings or error messages, only available hidden behind the details button. For an expired signature or a revoked key, there's just no green bar and no icon, show as if it was unsigned. Never show a signed mail as less trustworthy than unsigned mail. Don't think there is much of a use case for looking at old signatures, it's mostly for current mail to prevent spear phishing etc.

Mailpile: Similar. Add delimiters within message display to show what is signed or not. If historic data indicates that the sender ususally signs, then anomalies may show a scary red icon, but otherwise the UI is relatively quiet about it.

ProtonMail: Differs depending on whether there is a key pinned for that contact. Display "nothing", a checkmark, or an X. (discussion)

Mailfence: If we have a signature, we clearly mark as green. If it's not valid, we show a red bar. And then the third case is we have a signed mail, but no key to validate, show it's signed by someone but we don't tell you if it was a good or a bad signature. Unsigned mails have no markers.


Q: Did the pros in the room do usability testing?

Mailfence: We launched iteratively, responded to user feedback.

(discussion went elsewhere)


(Whiteboard discussion of different timestamps)

DKG: Points out about 14 different data points that relate to time, that might be considered input into evaluation of the validity of a signature and communicating to the user.

MailFence: Talk about how they embed user-visible artefacts inside the (encrypted/signed) message body that make it more visible if a message is replayed.


Discussion about how signatures are used in the mail client: - Direct display - Input into evaluation of sender crypto capabilities - Input into GnuPG's TOFU database - Seeing signatures is a sign a key is in use, useful to rank keys when importing (Discussion about caching verification results, vs. evaluating every time a message is displayed.) Revocation is the main exception from caching being useful. Discussion of revocation semantics.


Outcome: Signatures and dates are being used in very different ways in different e-mail apps. Which is interesting! Room for much more conversations and learning from each-other.

Session 4 - protected headers

protected headers (memoryhole)

implementers feedback regarding rfc822 fallback

we need a new home

next steps

Day 2 + GDPR concerns

session about unspoofable security indicators

Primary focus: html spoofing of security indicators

we want the chrome to be nearby, but the closer it is the harder it is for users to distinguish between content and chrome.

should we just get rid of the ability to see html?

what about indicators in the message list?

can we populate the sender line/headers? because those parts can't be manipulated by the body.

kmail has problems where we don't have single signature state.

pgp inline is problematic, especially for piecemeal-signed.

dkg suggests that we have only one signature state per message.

rendering mails as text-only, with a button to allow views of HTML formatting

people receive all kinds of bizarre messages.

pgp partition spec means that mails arrive with multiple statuses per part. symantec endpoint security, gpg4o both generate this.

stefan says "if there's an inline encrypted blob in a cleartext message, let the user decrypt it manually"

dkg proposes limiting cryptographic status to "cryptographic envelope" vs. "cryptographic payload" -- only use the set of layers of MIME crypto at the very outside of the message.

if we move to one-status-per-message, Mailing list signatures are going to be the first fatality.

University of Bochum sent mail to many MUAs about spoofable UI indicators. we should be prepared to link to that work when complaints come in about simplified display:

Should we ensure that insecurity indicators take up the same amount of space as security indicators, so that the space is reserved?

Andre has different security indicator levels in bars above the message, and also up in the upper right.

Bjarni (not present) is proposing showing insecurity for mails from a user who has sent all secured mails in the past. Stefan points out that this doesn't work for random spoofing from unusual addresses.

Andre points out that there's a marketing issue for plugins -- they want very visible indicators to prove that they're doing something.

maybe we can consume a lot of space by default, but let users minimize the space, and when they choose to do that, we have an opportunity to educate them to look for the smaller indicators.

Session: Timestamping for Signature validation

Session slides:

Signature Validity / Display

Protonmail: No signature No key Failing signature verification

GnuPG/Outlook Plugin:

Concept of verified sender address: not making an assumption about identity, only make an assumption about sender address, that it was not faked.



K9 Mail

Changing behavior can be monitored: if we have a history of that contact and changing signature information, then we can make assumptions about the validity of signature.

Signatures are made without context. Intended recipients field: this message is signed and should be encrypted for this and that fingerprints.

Mailpile also shows red state for signature verification fails.

Agreement: should be a binary state if a message was valid signed or not. There could be a second parameter that makes a statement about the trust on the key.

Session: Deletable Email

EmailSummit2018Notes (last edited 2018-10-31 08:32:06 by ilf)