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

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Feb 2019 21:32:54 -0500 (EST)

Via twitter I noticed this draft:

https://tools.ietf.org/html/draft-mccain-keylist-02

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.

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.

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?

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)

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?

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.

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?

What to do when the email on the key list points to a key lacking that
key ID ?

Why not use https://wiki.gnupg.org/WKD ?

Why not use OPENPGPKEY DNS records?

While automatic sync is a nice feature, over-syncing is a privacy risk,
especially for people who are trying to remain anonymous.

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

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 13 Feb 2019 12:10:50 +0100

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

-- 
https://metacode.biz/@wiktor

---

From: Micah Lee <[email-masked]>
Date: Wed, 13 Feb 2019 12:31:33 -0800

Hello,

I'm adding Miles McCain to this email, who is one of the authors you
left out. And I'm also adding the [email-masked] mailing list.

> 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

> 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 ([email-masked]) 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.

> 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

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

> these. (for example, to avoid publishing it in the final RFC)

This is good feedback.

> key loss or compromise? How does the manager / key talk to its users

Interesting, I'll take a look at the Security Considerations document.

> confidentiality for a key list. Anyone with the URI can get the list

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.

> 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

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

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

> an protocol issue and not an application issue.

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

---

From: "R. Miles McCain" <[email-masked]>
Date: Wed, 13 Feb 2019 15:50:18 -0500

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

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 13 Feb 2019 22:22:23 +0100

Hi Micah,

Thanks a lot for the explanation. I was about to ask you these questions 
previously on keylist ML but it never happened...

I'll skip parts that I don't have any comments for.

On 13.02.2019 21:31, Micah Lee wrote:
> up-to-date. But 1) Not all OpenPGP users use gpg and cron,
I think one of the strengths of GpgSync, as an application, is that it 
does the key refresh in the background, has a nice, simple UI and is 
cross platform. I wouldn't definitely advise setting up crons but rather 
having GpgSync do something like that (maybe not exactly invoking `gpg 
--refresh-sync` but see my next point).
>   and 2) we

Parcimonie [0] addresses that problem by using fresh Tor circuit for 
each key.

[0]: https://github.com/EtiennePerot/parcimonie.sh#parcimoniesh

Not refreshing all keys may leave some other keys (for example people 
that the journalist communicate with) stale. I don't have a problem with 
that but I think it'd be good be aware of this.

> automatically fetch*new*  keys that they otherwise wouldn't be aware of.
Yes, but WKD keys are downloaded on demand when they are needed, e.g. 
when you type a new message, or verify an unknown signature. Unless you 
want to have the keys locally because someone is encrypting the file 
while being offline and only later sends it out, then keys locally are a 
nice thing to have.
> without having to do manually fetch it and verify it first?
As I said, the key could be fetched on demand. As for authorization it 
already happens via Authority Key (that is lsigned by each user) signing 
other users keys and that doesn't change regardless of how the key got 
into local keyring in the first place.
>   Or, let's

You can deliver both keys, revoked and new, also over WKD (see [1]). 
That'll revoke the old key and make the new one active.

[1]: https://lists.gnupg.org/pipermail/gnupg-users/2019-January/061439.html

Of course, getting correct keys for unsupported or not controlled 
domains (mit.edu/gmail.com) is a problem that having an official, 
organization keylist solves quite nicely. I think emphasizing this in 
the keylist abstract may be a good idea.

Thank you for your time!

Kind regards,

Wiktor

---

From: Paul Wouters <[email-masked]>
Date: Sun, 17 Feb 2019 21:17:24 -0500 (EST)

On Wed, 13 Feb 2019, Micah Lee wrote:

> left out.

Oops. sorry about that.

> 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

> regularly-changing document, so I don't think it's in scope for this

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.

> RFC, supports an option mitigate this issue by making it simple to fetch

So that would be good to mention in the draft!

> KEY BLOCK-----"-type blocks. But that format isn't appropriate for

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?

> new key is added, but every single time anyone in the the organization

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.

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

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

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

> keylists, but it's not something we have considered yet.

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

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

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

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

> 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

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

> feeds, and existing automated use of key servers, have always had this

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.

> subscribing to keylists would be perfect fine, and would not compromise

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.

> 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

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

> 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