(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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users