Subject: [dns-privacy] ALPN protocol ID for DoT

From: "Reed, Jon" <[email-masked]>
Date: Thu, 12 Dec 2019 15:01:05 +0000

Hi all, 

I'm planning to request a registration of an ALPN ID[1] for DNS-over-TLS.   One primary use case we have is supporting both DoT and DoH on port 443, when port 853 is blocked between clients and the servers (this is by mutual agreement, as discussed in RFC 7858 § 3.1).   I plan on requesting the protocol ID 0x64 0x6F 0x74 ("dot"), following the conventions of using all lowercase in registrations.

Per discussion with one of the expert reviewers, I'm polling the list to see if anyone has objections -- if so, please let me know.  I'd be interested in hearing the objections, and what alternatives might be proposed.

Thanks,
Jon

[1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids <https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids>

--
Jon Reed
[email-masked]
Nameservers Service Performance
Akamai Technologies

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Dec 2019 15:34:09 +0000

On Dec 12, 2019, at 7:01 AM, Reed, Jon <[email-masked]> wrote:
> [1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

This was discussed during the creation of RFC 7858. I would summarize the WG discussion as follows:

- It is fine technically.

- It will cause confusion because there will be two ways to do DoT, so a client might have to test each way in order to know if the resolver supports DoT.

- It is easier for clients to configure a different port than to configure ALPN. In fact, many clients cannot configure ALPN at all.

Others may have different summaries from the discussion. Certainly, some folks will have strong support or objections to those points; WG consensus was not particularly easy on this topic.

Having said that, Jon brings up a good point that we did not predict four years ago, namely that some resolvers might already be offering privacy services on port 443.

--Paul Hoffman

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 13 Dec 2019 11:36:48 +1100

On Fri, Dec 13, 2019, at 02:34, Paul Hoffman wrote:
> - It will cause confusion because there will be two ways to do DoT, so 
> a client might have to test each way in order to know if the resolver 
> supports DoT.

This is a curious assertion.  HTTPS operated for many years without ALPN.  Right now, you negotiate HTTP/1.1 with the tag "http/1.1" OR by omitting ALPN.  The same would seem to apply here equally.  Of course, using DoT on port 443 means that you might not get the default you want, so this is a fine thing.
 
> - It is easier for clients to configure a different port than to 
> configure ALPN. In fact, many clients cannot configure ALPN at all.

This depends very much on deployment.  But there is another consideration: without ALPN, you have the potential for client and server to disagree on what the protocol is.  We've seen practical attacks based on that confusion.

I think that using ALPN for new protocols is not just OK, but virtually a necessity.

---

From: Allison Mankin <[email-masked]>
Date: Thu, 12 Dec 2019 20:12:00 -0500

Thanks for checking. I recall we co-authors of RFC 7958 talked about ALPN
for DoT before (can't recall if it bubbled up to WG discussion). It seems
useful to me now.

Question for the WG:
Would we want to update RFC 7858 (or RFC 8310) to indicate the ALPN ID
exists? This would be for the sake of future implementors, whether they
want to run DoT and DoH, or want to cautiously run only DoT on 443.

Allison

On Thu, Dec 12, 2019 at 09:01 Reed, Jon <[email-masked]> wrote:

> Hi all,
>
> I'm planning to request a registration of an ALPN ID[1] for DNS-over-TLS.
>   One primary use case we have is supporting both DoT and DoH on port 443,
> when port 853 is blocked between clients and the servers (this is by mutual
> agreement, as discussed in RFC 7858 § 3.1).   I plan on requesting the
> protocol ID 0x64 0x6F 0x74 ("dot"), following the conventions of using all
> lowercase in registrations.
>
> Per discussion with one of the expert reviewers, I'm polling the list to
> see if anyone has objections -- if so, please let me know.  I'd be
> interested in hearing the objections, and what alternatives might be
> proposed.
>
> Thanks,
> Jon
>
> [1]
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
>
>
> --
> Jon Reed
> [email-masked]
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 13 Dec 2019 12:25:42 +1100

On Fri, Dec 13, 2019, at 12:12, Allison Mankin wrote:
> want to run DoT and DoH, or want to cautiously run only DoT on 443.. 

Something like this doesn't need to update RFC 7858, any more than RFC 7301 updated RFC 2818 when it defined "http/1.1".  It can be a small, standalone document.  If there were a reason to reopen RFC 7858 (or 8310), then I would definitely roll the change in, but the fix doesn't need to be very disruptive.

---

From: Allison Mankin <[email-masked]>
Date: Thu, 12 Dec 2019 20:33:36 -0500

Reasonable. But a small RFC isn't automatic with the registration of the ID
at IANA. I like the small RFC path.

On Thu, Dec 12, 2019 at 19:26 Martin Thomson <[email-masked]> wrote:

> Something like this doesn't need to update RFC 7858, any more than RFC
> 7301 updated RFC 2818 when it defined "http/1.1".  It can be a small,
> standalone document.  If there were a reason to reopen RFC 7858 (or 8310),
> then I would definitely roll the change in, but the fix doesn't need to be
> very disruptive.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 13 Dec 2019 12:37:38 +1100

On Fri, Dec 13, 2019, at 12:33, Allison Mankin wrote:
> Reasonable. But a small RFC isn't automatic with the registration of 
> the ID at IANA. I like the small RFC path.

As do I.  I think that the IETF can and should publish RFCs for this sort of change.

---

From: "John Levine" <[email-masked]>
Date: 12 Dec 2019 23:18:23 -0500

In article <[email-masked]> you write:
>- It will cause confusion because there will be two ways to do DoT, so a client might have to test each way
>in order to know if the resolver supports DoT.

I have no objection to reserving an ALPN ID for DoT for use by private
agreement, but I'd be pretty unhappy if it became a de-facto
alternative to port 853.

We really need to figure out how to do DoWhatever discovery,
preferably better than probe ports on the same IP as the port 53
server.

R's,
John

---

From: "Reed, Jon" <[email-masked]>
Date: Fri, 13 Dec 2019 12:05:50 +0000

> On Dec 12, 2019, at 11:18 PM, John Levine <[email-masked]> wrote:
> 
> agreement,

That is precisely what I am proposing.

> but I'd be pretty unhappy if it became a de-facto
> alternative to port 853.

If a small RFC is published, as others have discussed, I would support a statement to the fact that ALPN-capable resolvers SHOULD NOT (MUST NOT?) require the ALPN identifier when accepting DoT connections on 853.  

Ports other than 853 don't impact opportunistic DoT, since you have to have prior mutual agreement of the alternative port.

> preferably better than probe ports on the same IP as the port 53

Agreed.

-Jon

---

From: "John R Levine" <[email-masked]>
Date: 13 Dec 2019 10:22:24 -0500

> Ports other than 853 don't impact opportunistic DoT, since you have to have prior mutual agreement of the alternative port.

Sounds good to me.  Tnx.