Hello,
I'm adding Miles McCain to this email, who is one of the authors you
left out. And I'm also adding the keylists(_at_)freelists(_dot_)org 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 (keylists(_at_)freelists(_dot_)org)
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?