WKD proper behavior on fetch error
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sun Jan 24 16:14:05 CET 2021
On Fri 2021-01-22 22:59:36 +0000, Andrew Gallagher via Gnupg-users wrote:
> On 22/01/2021 17:29, Daniel Kahn Gillmor via Gnupg-users wrote:
>> this is a non-backward-compatible change to the format, so i think
>> that's probably not a great outcome.
> I can't help thinking that length fingerprinting and padding oracles are
> a general concern, and therefore more appropriately solved at a lower
> layer of the network stack.
they are definitely a general concern for HTTPS -- and that's why TLS
1.3 includes a mechanism to provide padding at that layer as well.
However, if the adversary can determine *what kind* of https traffic
this is (a hint which is pretty clear given the openpgpkey.* domain name
in the SNI of the TLS handshake), then the domain of the padding is much
more specific. In particular, the adversary already knows the
*application* layer, not just the transport layer.
In such a case, the padding is best done closest to the application
layer itself, because the transport layer generally doesn't know what
the application layer is doing. But padding at both layers might not be
bad, if you can afford it.
padding as a defense against traffic analysis is far from a solved
problem, generally. :(
More information about the Gnupg-users