Subject: [openpgp] Web Key Directory and advanced lookup method

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Mon, 15 Apr 2019 20:02:24 +0200

Hello,

I'd like to ask about the (potential) issue with advanced lookup method 
in WKD.

For those that don't remember what it is it converts e-mail (such as 
"[email-masked]") into a URL that uses "openpgpkey" subdomain of 
the e-mail domain (in this case 
"https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe"). 
[0]

There are some domains that allow users to register subdomains with any 
name the user requests (with some exceptions). For example "github.io". 
So if a user selects "openpgpkey" as a name and thus will be able to 
host files under the ".well-known" directory they will effectively 
intercept all WKD queries for e-mail addresses for that domain.

That is query for key for "[email-masked]" will go to the user that 
registers "openpgpkey" name.

The problem of domains under which Internet users can directly register 
names also exists in browsers. To avoid various security issues w.r.t. 
supercookies Mozilla manages Public Suffix List [1] that is used by all 
major browsers. The list is quite big [2].

I did take a look at MTA-STS [3] as it also uses subdomain but in 
MTA-STS's case they first start with DNS TXT record query and only then 
query mta-sts subdomain so mere registration of subdomain wouldn't 
trigger MTA-STS.

I don't want to suggest any fixes to the spec just inquire if you think 
it's a real issue or rather a quite obscure edge case.

Thank you for your time!

Kind regards,
Wiktor

[0]: 
https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07#section-3.1

[1]: https://publicsuffix.org/

[2]: https://github.com/publicsuffix/list/blob/master/public_suffix_list.dat

[3]: https://tools.ietf.org/html/rfc8461

-- 
https://metacode.biz/@wiktor

---

From: Bart Butler <[email-masked]>
Date: Thu, 18 Apr 2019 18:21:01 +0000

Hi Wiktor,

This is a good point and I do not think it's been discussed before. The reason WKD can't use the TXT record is that browsers can't look up TXT records, all they can do is try to resolve domains.

I'd say that this is less of an attack vector and more of a 'mischief' vector, and that public suffixes can easily protect themselves if it ever becomes an issue. WKD client implementations can also use the public suffix list themselves to prevent the problem--a quick search yields libraries for lots of platforms. Maybe this would be a reasonable suggestion to add to the RFC, but it also doesn't seem critical to me.

Cheers,

Bart

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 

> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Thu, 18 Apr 2019 22:27:19 +0200

Hi Bart,

> This is a good point and I do not think it's been discussed before. The reason WKD can't use the TXT record is that browsers can't look up TXT records, all they can do is try to resolve domains.

Oh, I was not suggesting adding TXTs - believe me I'd like to have a 
good Web compatibility too (that's why I asked about CORS previously, 
and well... added support for WKD to OpenPGP.js :).

> I'd say that this is less of an attack vector and more of a 'mischief' vector, and that public suffixes can easily protect themselves if it ever becomes an issue. WKD client implementations can als…

Got it, thank you for your remarks! I was thinking about using just the 
bare domain lookup (without subdomain) that avoids the issue altogether. 
And if someone wants to delegate hosting keys to someone else adding 
permanent redirect in HTTP server is usually simple (Nginx example):

   location ~ /.well-known/openpgpkey/(.*) {
     return 301 https://example.com/.well-known/openpgpkey/$1;
   }

Kind regards,
Wiktor

P.S. I'm eagerly waiting for ProtonMail to add support for WKD too! :)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 19 Apr 2019 03:27:43 -0400

> and well... added support for WKD to OpenPGP.js :).

The interesting thing about MTA-STS's fix is not that it was a TXT
record, but rather that offers a gating mechanism for a domain to
explicitly opt into the protocol, rather than everyone being
automatically opted-in (and therefore potentially spoofed in the way
that Wiktor is concerned about).

Is there some analogous semantics that we can offer that would still be
accessible from the browser?

Or, if we decide to gate WKD by a TXT record, can a javascript
in-browser implementation use something like DoH to do the TXT lookup?

> bare domain lookup (without subdomain) that avoids the issue

I'm pretty sure i don't like the bare domain lookup, and would prefer
that that fallback was removed from the draft.  If i give you the
ability to place files on my website, i don't expect you to be able to
assert e-mail identity information for me or for my users.

>      return 301 https://example.com/.well-known/openpgpkey/$1;

The draft doesn't seem to mention whether clients should follow HTTP
redirects, or what the privacy/security/performance impacts of such a
practice are.

For example, should a WKD client follow an HTTP redirect to an http://
(not https://) site?  If the other site redirects, how many layers of
redirection should be followed?

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 19 Apr 2019 03:18:25 -0400

On Thu 2019-04-18 18:21:01 +0000, Bart Butler wrote:

> I'd say that this is less of an attack vector and more of a 'mischief'
> vector, and that public suffixes can easily protect themselves if it
> ever becomes an issue.

Why is this merely "mischief"?  I can publish semi-authoritative records
about the key material for all your users if you grant me access to a
single specific subdomain. without noticing the appearance of this
draft.  That sounds like more than mischief to me.

> WKD client implementations can also use the public suffix list
> themselves to prevent the problem--a quick search yields libraries for
> lots of platforms. Maybe this would be a reasonable suggestion to add
> to the RFC, but it also doesn't seem critical to me.

Resorting to the public suffix list is always a terrible solution, but
maybe it's what we have to rely on.  Writing down the explicit guidance
on what to do there, and what it's implications are, is probably a good
idea for thinking it through.  Would this suggest, for example, that no
e-mail address within @github.io would be able to effectively publish
their OpenPGP certificate via WKD?

      --dkg