Mailing List Archive

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@wkdtest.pgp.16bits.net
alice.rsa@wkdtest.pgp.16bits.net
alice.ecc@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@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@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@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.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Wed, Jan 20, 2021 at 12:41 AM Ángel <angel@pgp.16bits.net> wrote:

> A list of all (well, most) openpgpkey subdomains can be easily created.

Yes and I believe that what Neal and you (in your new posting) have explained
makes it only worthwhile for Mallory to start his work, because he has such an
openpgpkey list created. Anyways, even if creating and maintaining a list also
for all domains (direct-method) why give him this opportunity, if it
is so easy to
do so for openpgpkey subdomains? There is a demand for openpgpkey, so
it seems, which I have accepted, but you know my points (which I have outlined)
in the whole thread that we should be allowed to have direct-method usage too,
with GnuPG and gpg4win, without having cert errors in GnuPG and gpg4win's
WKD implementation. Whatever the outcome of this thread will be, as long
as other OpenPGP apps work and will hopefully not change, so that this no
longer works, people know now what they can do/use.

Best regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

(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

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.

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.

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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@wkdtest.pgp.16bits.net The same padding with nuls

alice.literal@wkdtest.pgp.16bits.net Padding with a literal packet
alice.marker@wkdtest.pgp.16bits.net Padding with a marker packet
alice.secret@wkdtest.pgp.16bits.net Padding with a secret key packet
alice.experimental@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@wkdtest.pgp.16bits.net),
but it has the same issue of being compressible.


I also prepared dynamic.keys@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/????????????????????????????????


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Thu 2021-01-21 18:49:19 +0100, Neal H. Walfield wrote:
> 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.

fair enough. It also doesn't allow arbitrary trailing NUL octets to
follow it, so i was just trying to at least make the subsequent octets
parseable. But i agree that perhaps there are still potential failures.

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

i think many implementations would treat a signature from an unknown
party as something worth keeping. that is, they wouldn't be able to
distinguish a bad signature from an unknown signature. so another
approach would be to create a bad signature that claims to be from the
primary key itself -- that is a *known bad* signature, so it should be
possible to discard it.

> We could append a public key packet with fixed creation time and MPIs,
> and a direct key signature, which is filled with junk.

Interesting. this would likely be interpreted as the start of another
OpenPGP certificate, if i understand correctly. at the moment, i think
wkd instructs client to expect at most two certificates (one expired and
one active), but i don't know whether clients are strict about this
check. this would show up as a third certificate.

> Implementations would detect this as an invalid key for several
> different reasons (no valid self signature, for instance).

The risk with this approach is that an implementation that isn't strict
about requiring a valid self-signature might see this as a usable key
for the address they're looking up in WKD. What if the public key
packet was instead using a reserved algorithm? then it would be
unparseable and unusable by the client even if they mistakenly thought
it was the right one?

> And, implementations in the know could recognize the public key packet
> as being padding and no even emit a warning about an invalid
> certificate.

That would definitely be a nice outcome. a dedicated/dummy key type
would facilitate this kind of discarding too. what do you think?

> Another approach to make the data uncompressable would be to encrypt
> the keyring with, say, AES and include the key.

this is a non-backward-compatible change to the format, so i think
that's probably not a great outcome.

--dkg

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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.

A

On Fri, 22 Jan 2021 23:59:36 +0100,
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.

Padding needs to happen as close to the application as possible.

Consider the case where an application has two possible responses: a 1
bit response and a 100 MB response. Most padding schemes won't
obfuscate these two responses. Using dkg's suggestion, all 1-bit
responses would be padded to 4k and hence all responses would still be
fully distinguishable.

For a padding scheme to be useful, many different types of messages
must end up in the same size bucket. Ensuring that requires
application-specific knowledge.

Neal

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

--dkg

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users