Re: [openpgp] comments on draft-mccain-keylist-02

["R. Miles McCain" <[e-mail]>]

Hello all,

I am writing to announce that we have released a new version of
draft-mccain-keylists (draft-mccain-keylists-04) based on the feedback we
received from members of this working group—namely, Paul Wouters and Wiktor
Kwapisiewicz. Thank you for all your help.

The changes in this new version can be viewed at
https://github.com/firstlookmedia/keylist-rfc/pull/11/files#diff-ecd5aee0533eca34044c2ff3f965c68f

The draft itself is published at
https://datatracker.ietf.org/doc/draft-mccain-keylist

We were not able to fully address each comment in this draft, of course, so
any and all further feedback is extremely helpful. We do think, however,
that our changes in v04 implement most of the suggestions (and alleviate
many of the concerns) raised by earlier comments.

Regards,
Miles


On Wed, Feb 13, 2019 at 3:50 PM R. Miles McCain <[e-mail]> wrote:

> Thank you, Micah, for adding me to this email. I would like to just add
> here that our freelists.org mailing list has yet to be meaningfully used,
> and we would be absolutely willing to move discussion to an appropriate
> IETF-managed mailing list. (Because our draft has yet to be assigned
> to/adopted by any working group, we didn't have an IETF mailing list we
> could use for discussion.)
>
> That being said, we have made our best efforts to encourage discussion
> within the IETF community—including announcing our draft to SecDispatch.
>
> Thank you for the useful comments so far; we will work to incorporate this
> feedback in future versions of the draft.
>
> Miles
>
>
> On Wed, Feb 13, 2019 at 3:31 PM Micah Lee <[e-mail]>
> wrote:
>
>> Hello,
>>
>> I'm adding Miles McCain to this email, who is one of the authors you
>> left out. And I'm also adding the [e-mail] mailing list.
>>
>> On 2/12/19 6:32 PM, Paul Wouters wrote:
>> > Via twitter I noticed this draft:
>> >
>> > https://tools.ietf.org/html/draft-mccain-keylist-02
>>
>> Note that a new draft has since been published, however the changes are
>> minor: https://tools.ietf.org/html/draft-mccain-keylist-03
>>
>> > I have some comments on the draft. I've added the authors to the CC:
>> > since I'm not sure if they are on this list.
>> >
>> > First a procedural item. Section 1.3 states:
>> >
>> >    1.3.  Note to Readers
>> >
>> >    RFC Editor: please remove this section prior to publication.
>> >
>> >    Development of this Internet draft takes place on GitHub at Keylist-
>> >    RFC [1].
>> >
>> >    A mailing list is available for discussion at Keylists mailing list
>> >    [2].
>> >
>> >
>> > I just wanted to share with the authors that this is not the way one
>> > writes RFCs. RFC's and the IETF are covered by rules, such as the Note
>> > Well. Please see https://www.ietf.org/about/note-well/
>> >
>> > This is important because everyone discussing this draft on this list is
>> > expected to fall under the rules of the Note Well, meaning they cannot
>> > go out and get a patent and not mention anything until this document is
>> > an RFC, and then start charging money. And discussion at an external
>> > site as the draft authors suggest, is not protected by this mechanism.
>> >
>> > Furthermore, IETF carefully archives all mailinglist messages which can
>> > later also be used in discovery but also for late-comers to the
>> > discussion. If an outside website suddenly vanishes, all this
>> > information is lost. Finally, IETF has Chairs and a Sergant-at-arms to
>> > guide any on-list discussion. elsewhere, we fall under other possibly
>> > arbitrary rules. I'm not saying your suggested locations are (I didn't
>> > go there) but as a rule discussions on internet drafts happen on
>> > internet lists. Work elsewhere is brought back to the IETF. Eg you can
>> > make a pull request on github but you discuss this on an IETF list.
>>
>> It's good to understand how RFCs are supposed to get discussed and
>> written. I, as well as the other two authors, are new to the IETF
>> process. However I don't see how the Note Well is especially relevant to
>> this draft RFC, as there has been no talk about patents.
>>
>> We have a mailing list for this project ([e-mail]) though
>> admittedly we haven't been using it. Instead we've been using a chat
>> room hosted by a third party.
>>
>> Can you point to a document that describes the policy you're referencing
>> about where discussion of the RFC should take place, and also where
>> collaboration of writing the actual document should take place? We
>> definitely want to be transparent about the whole process.
>>
>> > Now to the draft itself,
>> >
>> >
>> > Section 2 talks about subscribing to "key lists", where a "key list" is
>> > defined as an URI to something and a fingerprint of a public key that is
>> > authorative for this list.
>> >
>> >
>> > Section 2.2 talks about regularly updating the key list, and performing
>> > daily checks at the URI. I think this could be a privacy issue, and one
>> > could track a traveling journalist based on their key list sync checks.
>>
>> It's true that there's a potential privacy issue with regularly fetching
>> updates, but it's the same issue that all subscription systems have,
>> such as Atom feeds (RFC 4287). It's also the same issue if you configure
>> gpg to refresh your keyring on a regularly interval.
>>
>> This privacy issue is more of a fundamental problem with how networking
>> works than with any specific standard that relies on subscribing to a
>> regularly-changing document, so I don't think it's in scope for this
>> specific RFC to tackle.
>>
>> However, GPG Sync, software that already implements the draft keylist
>> RFC, supports an option mitigate this issue by making it simple to fetch
>> updates over Tor:
>>
>> https://github.com/firstlookmedia/gpgsync/wiki/Using-GPG-Sync-with-Tor
>>
>> > section 3.
>> >
>> > The key list is a JSON format that can contain a reference to an
>> > external key server. This also sounds a bit dangerous to me. Instead of
>> > all clients forking out to possibly many key server locations, why isn't
>> > the "key list" simply an openpgp format public keyring, with trust
>> > attributes set properly by the "management key" ? Clients can HEAD the
>> > file and if there is an update, GET the file via HTTP and import the
>> > updates. I don't understand why there is indirection allowed or required
>> > in this idea.
>> >
>> > Because no openpg keyring format is used, this "key list" needs to be
>> > separately signed by the management pgp key. It adds another level of
>> > indirection that could be avoided. If I have sufficient "trust" set
>> > in my personal keyring to trust updates from the manager key, then
>> > I can get the updated in openpgp format without further new protocols
>> > already.
>> >
>> > The "key list" contains comments such as an signature_uri that allows
>> > the key list URI and the signature to be located on different systems?
>> > Why would that ever be useful or more secure than doing a cleartext
>> > signature on the file itself hosted on the same server as the key
>> > list file itself?
>> >
>> > A key list entry contains a fingerprint, name and email field? So in
>> > essence, this becomes a meta key-server. Why give participants all
>> > these indirections, instead of just providing the openpgp keyring
>> > itself?
>> >
>> >
>> > Why is the key list not optionally (but hopefully) encryped to the
>> > participants to avoid a privacy leak to anyone who obtains the key list
>> > URI ?
>> >
>> > A key list entry has concept of a last updated time stamp. Does this
>> > mean that every "sync" I go out to all individual key servers to get
>> > keys from all participants just in case they might have updated their
>> > keys on the keyserver / fileserver of their choice? It seems this
>> > process is an ideal process for the centralized manager key to perform,
>> > instead of all participants?
>>
>> GnuPG keyrings are not defined by an internet standard. They're a custom
>> format that GPG developers made up, and have changed over time (for
>> example gpg2 keyrings aren't compatible with gpg1). Having keylists rely
>> on GPG keyrings would make it unfeasible for non-GPG OpenPGP users to
>> subscribe to an organization's keylist.
>>
>> The relevant standard you're probably thinking of is RFC 4880 which
>> defines the OpenPGP message format, basically the "-----BEGIN PGP PUBLIC
>> KEY BLOCK-----"-type blocks. But that format isn't appropriate for
>> keylist subscriptions.
>>
>> Keylists don't include full public keys, they only include fingerprints.
>> Information in public keys themselves change frequently -- the owner of
>> the key might add a UID, update their expiration date, or otherwise
>> modify their key. If keylists included actual full public keys, then the
>> person maintaining the keylist would have to update it not just when a
>> new key is added, but every single time anyone in the the organization
>> modifies their key.
>>
>> One of the main purposes of keylists is to reduce the amount of work
>> required to ensure that everyone in an organization (or anyone who
>> wishes to communicate with members of that organization) has the correct
>> public key for everyone else.
>>
>> Including full public keys in the keylist would be counterproductive.
>> The keylist that my company relies on currently has 228 fingerprints on
>> it, and it would add a ridiculous amount of pointless work to maintain
>> it if we had to keep track of minor changes in each key (and get copies
>> of those changed public keys from their owners), when instead we can
>> just keep track of fingerprints.
>>
>> > Section 4.
>> >
>> > The "in practise" section is usually called the Impliementation Status
>> > section. Please see https://tools.ietf.org/html/rfc7942 on how to write
>> > these. (for example, to avoid publishing it in the final RFC)
>>
>> This is good feedback.
>>
>> > Section 5.
>> >
>> > The security considerations usually does not contain the benefits. Those
>> > are the features offered and described in the document itself. This
>> > section deals more with the concerns or practical issues or general
>> > safe practises one has to keep in mind. Usually with a focus on
>> > implementors more than endusers. For guidelines on how to write a
>> > Security Consideration section, see https://tools.ietf.org/html/rfc3552
>> >
>> > The three benefits listed do not convey to me why this solution with a
>> > level on indirection is better suited that using a openpgp keyring
>> > at the location.
>> >
>> > I would rewrite 5.2 a bit. Yes the security of this system is only as
>> > strong as the security of the manager key. But how does one convey this
>> > management key? How is this key verified? What to do when the key IDs
>> > are different? What to do when the key list can be obtained but not
>> > the individual key servers listed for some participants. How often to
>> > retry? when to warn the user? How does one recover from a management
>> > key loss or compromise? How does the manager / key talk to its users
>> > about anything?
>>
>> Interesting, I'll take a look at the Security Considerations document.
>>
>> > The biggest problem though is that I see no attempt at providing
>> > confidentiality for a key list. Anyone with the URI can get the list
>> > of participants.
>>
>> Keylists are public documents, and anyone can subscribe to them even if
>> they're not a member of the organization.
>>
>> It might be worth considering the case where people wish to have private
>> keylists, but it's not something we have considered yet.
>>
>> > Why not introduce a .well-known location that any organisation can
>> > use, so we could try and find key lists for organisations we never
>> > talked to before. Perhaps specify a mechanism on how to verify an
>> > organisational management key?
>>
>> We considered introducing a .well-known location, but, as described in
>> the draft:
>>
>>    To subscribe to a keylist, the client must be aware of the keylist
>>    URI (see [RFC3986]), and the fingerprint of the authority key used to
>>    sign the keylist.
>>
>> A client must have both the keylist URI and the fingerprint of the
>> authority key to subscribe to it -- just the keylist URI is not enough,
>> which means a .well-known location would have to also include the
>> authority key fingerprint. Doing this would ultimately make the trust of
>> the entire system rely on the security of the organization's web server,
>> and on HTTPS, as opposed to on the authority key.
>>
>> And there's a further issue related to domains names which I describe
>> below.
>>
>> > What to do when the email on the key list points to a key lacking that
>> > key ID ?
>>
>> As described in the draft, only the "fingerprint" field of the key is
>> required, and all other fields (name, email, comments, and any other
>> arbitrary metadata) are optional, and only there for the sake of the
>> organization maintaining the keylist. Clients simply fetch the
>> fingerprint.
>>
>> > Why not use https://wiki.gnupg.org/WKD ?
>> >
>> > Why not use OPENPGPKEY DNS records?
>>
>> The members of an organization frequently don't have email addresses at
>> the same domain name. For example, my organization includes email
>> addresses at firstlook.org, firstlook.media, theintercept.com,
>> fieldofvision.org, topic.com, among other domains, not to mention we
>> frequently add personal email addresses hosted at gmail.com or other
>> email services, as well as university email servers, for interns,
>> freelancers, or other temporary workers. And some organizational keys
>> contain UIDs that don't include email addresses at all. Still, we want
>> to include all of these fingerprints on our keylist.
>>
>> A keylist contains a list of fingerprints for public keys everyone in
>> the organization should have. It would add more pointless work to
>> maintain this system if we chose to arbitrarily require that they all
>> keys contain UIDs with email addresses for the same domain name.
>>
>> Also, not all organizations even have a domain name of their own (for
>> example, a free software project where the code and releases are hosted
>> on GitLab.com, and members of the project use personal email addresses).
>>
>> > While automatic sync is a nice feature, over-syncing is a privacy risk,
>> > especially for people who are trying to remain anonymous.
>>
>> This is outside the scope of this RFC. Like I described above, Atom
>> feeds, and existing automated use of key servers, have always had this
>> problem.
>>
>> (Also, people trying to remain anonymous need to do quite a bit more
>> than just not automatically fetch PGP keys. It requires using an
>> operating system designed for such a use-case, like Tails, in which case
>> subscribing to keylists would be perfect fine, and would not compromise
>> anonymity.)
>>
>> > All in all, this seems like an interesting application, and worth
>> > further discussion (on this list). I am not yet convinced this is
>> > an protocol issue and not an application issue.
>> >
>> > Paul
>> >
>>
>> And finally, I'll also reply to Wiktor's feedback. (Quoting in full for
>> Miles' sake.)
>>
>> On 2/13/19 3:10 AM, Wiktor Kwapisiewicz wrote:> Hello,
>> >
>> > Excellent points and I'm glad that the draft has been published on this
>> > ML for a discussion in a wider audience.
>> >
>> > As far as I understood draft-mccain-keylist-02 its goals can already be
>> > achieved with a combination of already existing features:
>> >
>> > 1. Discovering keys for company employees - using "e-mail to key" lookup
>> > (e.g. WKD)
>> >
>> > 2. Trusting that these keys are authentic - by signing an Authority Key
>> > and setting ownertrust to full. This can be done only once and it works
>> > for all future keys. Even with draft-mccain-keylist-02 one needs to do
>> > that to know which keys are trusted. There is one variation of this
>> > scheme - by using Trust Signatures one can trust Authority Key to keys
>> > from the company domain only.
>> >
>> > 3. Keeping keys up to date - why not just refresh all keys in the local
>> > keyring? (e.g. `gpg --refresh-keys` or something similar). (GnuPG will
>> > refresh expired keys over WKD if they were fetched with WKD [0]).
>> >
>> > [0]: https://dev.gnupg.org/T2917
>> >
>> > If the problem is that people verify signatures and the keys are not
>> > present I think applications have appropriate options to fetch keys
>> > automatically (e.g. `gpg --auto-key-retrieve`).
>> >
>> > I like the point of using .well-known for a keyring of all people but
>> > from what I've heard on GitHub the ability to host keylist on a
>> > different domain is desired:
>> >
>> >> There's no reason to trust the server that hosts the keylist file. We
>> >> already don't trust it -- FLM hosts our keylist on GitHub.
>> >
>> > Source:
>> >
>>
>> https://github.com/firstlookmedia/keylist-rfc/issues/8#issuecomment-426846582
>> >
>> >
>> > Kind regards,
>> > Wiktor
>>
>> I've already addresses some of this, but:
>>
>> It's important for my company's use-case, and probably that of many
>> other organizations, to not tie a keylist to one specific domain name,
>> and to allow the keylist to include keys for personal email address
>> (e.g. gmail.com) as well as keys with UIDs that don't contain email
>> addresses at all. WKD is simply insufficient for this use-case. (It also
>> has the problem where if a member of the organization updates their key,
>> they can't push their updated key into the WKD like they can to a key
>> server.)
>>
>> It's true that we could bootstrap a system like `gpg --refresh-keys`
>> combined with cron (or more realistically launchd on macOS) to keep keys
>> up-to-date. But 1) Not all OpenPGP users use gpg and cron, and 2) we
>> don't necessarily want to update all keys in every user's keychain, only
>> the keys on the keylists they're subscribed to. Only refreshing keys
>> listed on a keylist leaks less information to key servers than
>> refreshing all keys -- it leaks what keylists you're subscribed to.
>>
>> But, most importantly, and in fact the reason we developed GPG Sync to
>> begin with (which ultimately lead to writing this draft RFC), what isn't
>> possible with existing tools is to get everyone in an organization to
>> automatically fetch *new* keys that they otherwise wouldn't be aware of.
>>
>> For example, lets say we hire a new intern, and they generate a PGP key
>> for their mit.edu email address. How do we get hundreds of people's
>> computers to automatically fetch that key so they can email this intern
>> without having to do manually fetch it and verify it first? Or, let's
>> say an employee loses their Yubikey, so they publish their revocation
>> certificate and generate a new key. How do we get those hundreds of
>> computers to fetch the revoked key, as well as the new key, so that the
>> next time someone sends an encrypted email to that person, it just works?
>>
>