WKD proper behavior on fetch error

[Ángel]

Hello all

First, I agree with Neal in considering there is a privacy leak in
using WKD (with no analysis/mitigations). 

dkg has already provided an excelent explanation about this, and seems
material directly usable into the Security Considerations section.


As noted, the openpgpkey server sysadmin has direct access to the full
email address being requested, not just because it would be trivial for
them to undo the hashing for all the they have, but the local part is
there ?l= query string (this was requested by protonmail in order to
process the actual email).

However, a network eavesdropper could as well obtain information about
the keys being fetched. 

For a practical example, watch the (encrypted traffic) while you
request the following keys:

alice.missing at wkdtest.pgp.16bits.net
alice.rsa at wkdtest.pgp.16bits.net
alice.ecc at wkdtest.pgp.16bits.net

The TLS 1.2 *encrypted* reply by the server is 250, 1474, 554. 


>From a recipient privacy point of view, you would ideally be connecting
to a server which has many users (a domain with a single-user would
immediately betray the recipient) which have openpgp keys (in this
sense, a public keyserver accessed via hkps are great), and also that
their keys are somewhat similar (e.g. all RSA 2048), so that they are
not distinguishable on the wire.

In this context, there would be a possible attack by tricking the user
into making their key recognizable.
If the aforementioned regime wanted to detect people writing to 
dissenting-newsroom at popularmailprovider.com, but not to anyone else at 
@popularmailprovider.com (let's assume mail clients now automatically
perform WKD, so requesting a key from popularmailprovider.com is not a
signal by itself), they could send an agent to provide to the people of
dissenting-newsroom at popularmailprovider.com their key with his
signature (or signed by all his friends), so that it stands out when
requested.


Of course, it would have been preferable for them to sign up at 
popularmailprovider.com with an account name which collides with 
dissenting-newsroom so they end up in the same bucket, and so they
would be able to add content there at will. But SHA-1 preimage
resistance makes that infeasible.


A WKD server operator could protect from this by padding the result
with other keys so that the actual key size is concealed. 

In order to simplify this, I would recommend stating that WKD clients
must ignore a trailing block of nuls (not part of a pgp packet,
obviously) so that keys can easily be padded without calculating
openpgp packets.

You can test this by requesting alice.padding at wkdtest.pgp.16bits.net
(gnupg chokes on this, since it is expecting a valid packet)

Note that doing this requires that the files are server with no
compression, as otherwise padding with nuls wouldn't really be
effective.


Best regards


PS: dkg email doesn't seem to have reached the list yet (only the one
from Jan 15 appear in the archives), although later messages are
already there.