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

[Paul Wouters <[e-mail]>]

On Wed, 13 Feb 2019, Micah Lee wrote:

> I'm adding Miles McCain to this email, who is one of the authors you
> left out.

Oops. sorry about that.

> 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.

> 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.

An overview can be found at https://www6.ietf.org/tao

See also: https://datatracker.ietf.org/meeting/103/materials/slides-103-edu-sessj-newcomers-overview-for-ietf-103-00

> 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.

If one would implement the RFC, what advise would you have to
implementors to reduce this risk? That's the text I'm looking for.

> 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:

So that would be good to mention in the draft!

> 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.

Yeah I was thinking of that.

> Keylists don't include full public keys, they only include fingerprints.

I guess that was a big point of my confusion. I was thinking of the
keylist having keys, not key pointers. So perhaps the term "key list" is
not the right term for this?

> 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.

But what scales better? An automated central way of pulling those
updates, and everyone else mirroring that, or everyone pulling all
these updates themselves? From a privacy point of view, the first would
be better. From an operational point of view I think the first would
give the best results too. But of course, there is a management issue
on how or what is responsible for this.

> 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.

Just a note, when you say organization, I mapped that in my mind to be
within a single (DNS) domain, or at least within the same administrative
control group. After reading your email, I understand things are meant
to work a lot more informal or scattered over dozens of domains.

> 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.

But wouldn't it be a simple cron job to refresh those keys every day?
And for your members to pull it all from the same location daily? The
additional burden you say you want to avoid is exactly te burden you
put on everyone who wants to use the key list?

>> 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.

I did not realise all keylists are public. Especially not reading the
opening sentence of the abstract:

    This document specifies a system by which an OpenPGP client may
    subscribe to an organization's keylist to keep its internal keystore
    up-to-date.

Note it specifically says "internal keystore". It would be better to
rephrase that to be the organisations public keystore?

> It might be worth considering the case where people wish to have private
> keylists, but it's not something we have considered yet.

That's worth mentioning somewhere then, possibly the Security
Considerations section.

>> 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.

So that is an important point. It would be great if we can somehow make
it so they keylists can be trusted via some way. So that if I want to
contact a journalist at firstmedia, I don't need to first somehow
contact the owner of the key that signed the keylist to confirm this is
the real key list (especially with references on members outside of the
actual domain name used by the organization).

We recently had a very similar discussion in SAAG about security.txt,
see:

https://tools.ietf.org/html/draft-foudil-securitytxt-05

https://mailarchive.ietf.org/arch/msg/saag/WoVRqcqmWdbE4mZo42XHBCKb9vg


Note that I'm myself not in favour of the current security.txt proposal,
but it seems that it might be worthwhile to see if your key list idea
and their universal pointer to contact information could work together.

> 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.

Ahh fair point. I'm still a little uneasy at keys changing and getting
new IDs and implying trust, but I guess that's out of scope for this.

Could you mention that fingerprints must be only in the long form, and
not the old short form that is no longer secure enough?

>> 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.

This is another important point that I completely missed after reading
the text. I assumed "an organisation" meant that only a very few number
of domains were involved. Perhaps clarify that in the draft?

> A keylist contains a list of fingerprints for public keys everyone in
> the organization should have.

To be fair here, you don't just want them to have a keylist. You want
them to have the public keys. And the keylist is a directory service to
get them. And I still think it might as well do the work and present it
all together.

> 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.

I agree. As I mentioned I hadn't thought of that scenario.

>> 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.

But the point of a Privacy Considerations section is to give important
information to implementors on issues that could pose a privacy risk,
and might be partially mitigated. So, instead of waving it out of scope,
try to give advise to implementors on how to mitigate this as much as
possible.

> (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.)

I don't believe it would be fine. Better sure, but there would still be
risks. A dissident could be announcing their presence as a coffee shop
if _any_ IP address queries for the updated key list. Tor does not
help that. Now I agree some of this is out of scope for your document,
but again think about what you'd want to advise implementors.

> 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.

That sounds like an argument for the key list to have the updated keys
for easy import by subscribers :)

> 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.

Sure, though let's hope that people only fetch keys over TLS so that at
least it is not known which keys are fetched?

> 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.

Right. But wouldn't a non-gpg specific standards based keyring format
not be a better and more universal solution?

Paul