'''''''[14:00 - sessions]'''''''

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

'''[15:00 - sessions]'''

'''Session 2: SKS keyserver - Kristian Fiskerstrand'''

## topic: 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 sks-keyservers.net, 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'''

''''''

 * will not break Autocrypt level 1

which features
--------------

 * key sync (public/private)
 * detection of active attack
 * alternate routing
 * ways to integrate with non-autocrypt topics (alternate force-encryption, etc)
 * key refresh (ECC? PQ?)
 * Protected headers
 * key rotation
 * workflow for device loss
 * MIME simplification
 * policies for subkey rotation/expiration
 * search of content of encrypted messages

Organizational process
----------------------

 * github process
 * regular IRC meetings

Can we do "level 1 compliant" badging?

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

 * propose asking about "level 1" compliance on mailing list.  if no
   unanswered objections are raised in two months.

potentially try to launch level 2 work before IFF 2019


easy
----
 * ECC keys
 * protected headers
 * MIME simplification

next up
-------

 * multi-device synchronization
 * verified contacts (and their implication of how the state changes)


next steps
----------

 * solicit level 1 compliance reviews

'''Session 2: MUA state sync'''

''''''

- What we want do sync?
 --> secret key -> answer (autocrypt setup message)
 --> Autocrypt state
 --> Address Book
 --> alternative routing
 --> general perferences of MUA (Signature, HTML, ...)
 --> rule settings policy
 --> tags, etc
 --> public key ring
 --> filter rules
 --> per message session key

- Properties to sync
 --> easy to use
 --> authenticated and confidential
 --> ongoing
 --> automatically
 --> more then two devices

- Ways we could the sync?
 --> kolab protocol an option?
 --> there needs to be a pairing mechanism -> whats the easiest way
 --> MLS -> group messages protocol
 --> syching protocol needs to allow message loss

- Risk and side Effects?
 --> end-up syncing to a device you want to sync to (avoid wire tap channel)
 --> deleting, duplication
 --> sync fails (deletetion of keys, ....)
 --> lateral movment after compromise

- Seperate in multiple Layers
 --> Define mechanism of pairing and sync -> how to establish an auth., conf,... channel not the syntax to sync
 --> Storage (IMAP, NextClout, Gdrive, ...)
 --> Whats to 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'''

'''[16:00 - sessions]'''

'''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. Expired or revoked keys show an red bar, but tell the user that it used to be valid. Users have to click through an info-icon to actually get details beyond "signature good/bad/unknown".

...

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)

- current state: spec was done in 2016, some clients did implement it
- the spec didn't really evolve
- no website anymore (modernpgp.org)
- naming of the alternative subject "Encrypted message"
- implementers feedback reg. fallback
- IETF Internet draft coming up by dkg & Alexey wrapping emails in rfc822 messages (LAMB(P?)S working group IETF, spasm)

## implementers feedback regarding rfc822 fallback

- fallback mode: a text part MUAs should display the user in case the client is not able to understand protected headers
- fallback mode: not optimal, because it adds just another MIME part, and increases the spec
- apple mail does include the fallback mode, mutt needs manual config, kmail shows it as well
- complaints: user get (or got, in the past) garbled message, some MUAs didn't decrypt these messages (in the past, mailfence maybe (?) still
  unfixed)
- complaints: threading doesn't work if based on the subject
- discussion about removing the fallback mode: pros and cons about keeping vs. removing
- schleuder: broken in the beginning when enigmail enabled protected headers by default; nowadays fixed, schleuder leaves the subject "as
  is" and works transparently
- K9Mail: not released / in the master branch, currently only implemented in a devel branch
- GPG4win: ?
- was there an effort directed at "all" of the MUAs asking for implementation, offering advice and help etc.: no, there wasn't such
  an effort; one reason for it was that there was never a complete spec
- currently rough consensus and running code: what about finalizing the spec and do a reach out to various MUAs?
- strip the spec down to a minimal level: just start with the subject, no References: etc. -> just encrypting the subject would be a good
  start, and could serve as a base to then do further iterations to encrypt more headers
- dkg starts a process to do an IETF draft
- feedback regarding the spec: sounds quite complicated because of multiple layers; proposal: just use the first MIME part inside the
  encrypted message
- the new IEFT draft might contain multiple layers as well; might make it complicated for MUAs what to display when
- protecting the From: header is complicated, because, depending on the MUA, it might be either impossible or pretty hard
- "Encrypted Message" subject: users might think that this serves as a security indicator
- proposal: remove the "Encrypted", use "No Subject" or "Subject unavailable" or "Embedded Subject" or "Hidden Subject" or no Subject:
  header (which are disliked by spam filters etc.)
- localization of the subject reveals the language
- fallback mode: adds additional implementation cost
- fallback mode: doesn't really help users of MUAs which doesn't support the spec (INBOX filled with mails with subject "Encrypted Message",
  therefore searching for a specific message based on the subject is not possible)

## we need a new home:

- modernpgp was the original home
- there is a repo on github which doesn't contain the content of the website

## next steps:

- stripping down the spec to a minimal level would be quite easy (TBA:  this evening, or tomorrow morning, the latest)
- leave aside the fallback mode, or make it optional (if it's just optional, maybe leave it out right from the beginning)
- where to put the new content: depends on the IETF draft and what should go in there (S/MIME? etc.)
- we're not bound to the IETF draft, so our "new home" doesn't depend on this -> no consenus / decision where this should be hosted


'''Day 2'''\\

# keys.openpgp.org + 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.

   https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html

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:

  https://www.golem.de/news/openpgp-gnupg-signaturen-faelschen-mit-html-und-bildern-1809-136738.html

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.


# Signature Validity / Display


Protonmail:
No signature
No key
Failing signature verification

GnuPG/Outlook Plugin:
- unsigned state / broken signature
- only some indication that this key is used by this user, no manually signing of the key, you only saw some signed mails of this key
- valid signature, still no manual interaction with the key. Used many times, pulled from WKD
- full validity, same level as in S/MIME trust, someone has certified the identity
- own keys, direct signature on other keys

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

Enigmail:
- either message is signed but no key, or signature invalid: signature not verified
- User id matching, Enigmal doesn't do it

Mailvelope
- no signature: nothing is displayed
- signature but no key: warning
- invalid signature: red

K9 Mail
- limited space for showing the signature verification result
- orange: signed and encrypted but no key, because actionable: the user can click on the orange sign and try to fetch a key from a key server
- message with Autocrypt header and signature will verify as valid

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-22 14:58:53 by Azul)