WKD proper behavior on fetch error

[Ángel]

On 2021-01-21 at 18:49 +0100, Neal H. Walfield wrote:
> On Thu, 21 Jan 2021 17:10:31 +0100,
> Daniel Kahn Gillmor wrote:
> > 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.
> 
> Please don't do this.  This is the format of a TPK:
> 
>   https://tools.ietf.org/html/rfc4880#section-11.1
> 
> It doesn't allow arbitrary packets to follow it, as far as I can see.
> 
> Let's stick to it.


We do have a bit of leeway here. This is not a "general TPK", as we are
defining it inside a protocol.
That's the context in which I considered it would be permissible to
ignore trailing NULs. 

My main consideration was that this allowed the admin to simply do¹

  truncate -s 4096 /var/www/html/.well-known/openpgpkey/hu/*

and get all the keys padded to 4096 (or whatever value he may want. He
would only need not to have real keys already larger than that). I
don't think we can expect most users to manually calculate a complex
padding.


Now, if the operators can't disable compression, that's a problem. 


> Now, there are few things we could do: we could inject a bad
> signature.  Some implementations won't discard bad signatures, so
> this is probably a bad idea.  We could append a public key packet
> with fixed creation time and MPIs, and a direct key signature, which
> is filled with junk.  Implementations would detect this as an invalid
> key for several different reasons (no valid self signature, for
> instance).
> And, implementations in the know could recognize the public key
> packet as being padding and no even emit a warning about an invalid
> certificate.

The right™ way would be to append a valid PGP key with an UID not
matching the hash. All implementations should already had considered
that possibility.

One could use a public key with e.g. a Public-Key Algorithm of 0, and
define that as a "null key" that should be skipped, but I'm not keen on
that since, it isn't really a public key. It is overloading a packet to
mean something different, for backwards compatibility.

I don't think we are at a point requiring such level of backwards
compatibility. There is only a handful of wkd implementations. The spec
is just a rfc, and we are finding cases where the implementations
differ, and will need to be changed, anyway. It would be a bad choice
to fossilize a hack like that.



dkg suggested an OpenPGP literal data packet. I suspect it may have
been an error, and rather than a Literal Data Packet (Tag 11), he may
have intended an _Obsolete_ Literal Packet, now Marker Packet (Tag 10).
If it wasn't, consider this a formal proposal to use it.

Tag 10 was never used by an official release, and 4880 says:
> Such a packet MUST be ignored when received.

A new no-op packet could be made, but Marker seems already a perfect
fit. Instead of putting "PGP", it would contain the padding data. The
content could start with e.g. "PADDING:" to make the intent even more
obvious, but the whole packet should have been ignored.

I have added several new test keys:
alice.nulpadding at wkdtest.pgp.16bits.net The same padding with nuls

alice.literal at wkdtest.pgp.16bits.net Padding with a literal packet
alice.marker at wkdtest.pgp.16bits.net Padding with a marker packet
alice.secret at wkdtest.pgp.16bits.net Padding with a secret key packet
alice.experimental at wkdtest.pgp.16bits.net Padding with an unknown packet

GnuPG imports without issues the key with a literal or secret packet,
but not with a marker, as it verifies (parse_marker) that it strictly
contains "PGP" :-/

4880 mentions that such is the content of a marker packet, but I was
expecting a more lenient parsing, given that there might be packets
generated from that unreleased version. It would be possible to pad
with a number of these (see alice.pgppgppgp at wkdtest.pgp.16bits.net),
but it has the same issue of being compressible.


I also prepared dynamic.keys at wkdtest.pgp.16bits.net which is simply
padded with other different, varying keys.
However note that gnupg only looks at the first 5 keys returned.



> >    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.
> 
> Another approach to make the data uncompressable would be to encrypt
> the keyring with, say, AES and include the key.

Do you mean to compress the returned file with AES? That would be a big
change from existing protocol. And you still need a way to separate the
padding from the key.



Regards

Ángel


¹ or, if you prefer
  truncate -s 4096 /var/www/html/.well-
known/openpgpkey/hu/????????????????????????????????