WKD proper behavior on fetch error

[Daniel Kahn Gillmor]

(my messages might not be arriving at @gnupg.org addresses right now
because their mailserver appears to be rejecting my mailserver claiming
(incorrectly, afaict) that the reverse DNS is not configured --
hopefully it will be resolved soon; feel free to re-forward this message
to the list if it doesn't show up there)

On Wed 2021-01-20 03:32:31 +0100, Ángel wrote:
> In this context, there would be a possible attack by tricking the user
> into making their key recognizable.

Yes, padding to protect the size of HTTPS traffic is important here.
The WKD client itself might want to also pad the query string since its
length will be variable based on the size of the l= parameter.

This is probably not the best mailing list to discuss either mechanism
or policy for HTTPS padding in particular, though.

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

Padding HTTPS traffic can already be done at the HTTP layer by adding
HTTP headers that will be known to be ignored.  I don't have a handy
reference for how to set that up, though, so it may be easiest for a WKD
operator to pad the distributed files directly.

Ángel proposes to pad with a block of nuls.  This is problematic for at
least two reasons:

 - it doesn't appear to be an OpenPGP packet, which might lead to the
   whole thing being rejected by a strict implementation

 - it compresses, which might reveal size in a compressed HTTPS session
   (Ángel recognized this flaw in his message, but doesn't propose a
   mitigation other than turning off compression, which might not be
   possible for some operators)

For WKD services which cannot control their webserver to disable
compression, and automate padding, a better approach would be to pad
each published key with an OpenPGP literal data packet, whose content is
filled with a high-entropy (uncompressable) stream.

Implementations that can parse OpenPGP packets will identify and discard
this packet (it is not part of any legitimate OpenPGP certificate); it
can't be easily compressed (due to the high entropy); and there won't be
any confusion about where the certificate ends, if the actual
certificate itself happens to end with any trailing nul octets.


Therefore, I'd recommend the following padding guidance be added to the
WKD draft to avoid the information leakage described:

While all transport for WKD uses HTTPS, the sizes of the requests and
responses may themselves leak information to a network observer about
the identity of the e-mail address looked up.  To avoid this leakage,
padding is advised:

 - A WKD client that provides the l= query parameter SHOULD provide an
   additional dummy query parameter, padding the size of the overall
   HTTP query string to a multiple of 256 octets.

 - A WKD client MUST NOT offer compression in the TLS handshake.

 - A WKD client's HTTP request MUST NOT offer to accept Transfer Coding
   or Content Coding that includes compression, including gzip,
   compress, or deflate.  {{someone more knowledgable about HTTPS should
   rewrite this to be more precise}}

 - An HTTPS server that publishes a tree of WKD information SHOULD NOT
   compress HTTPS responses whose URLs fall within that tree.

 - An HTTPS server that publishes a tree of WKD information SHOULD
   ensure that returned HTTPS responses with the WKD tree are padded to
   a multiple of 4096 octets.  Padding mechanisms might include:

   - a dummy HTTP header of sufficient length

   - appending a Literal Data packet to the returned OpenPGP certificate

   If the Literal Data packet padding mechanism is used, it SHOULD be
   filled with high-entropy randomness, in case some HTTPS server,
   reverse proxy, or other element in the data transmission chain tries
   to compress the certificate.

regards,

        --dkg