Subject: [dns-privacy] ADoT signalling

From: "John Levine" <[email-masked]>
Date: 3 Nov 2019 17:33:34 -0500

I thought it might be useful to make a list of possible ways to signal
that a server offers ADoT:

https://datatracker.ietf.org/doc/draft-levine-dprive-signal/

I'm sure there are others, feel free to send suggestions.

R's,
John

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 4 Nov 2019 15:09:10 +0100

On Sun, Nov 03, 2019 at 05:33:34PM -0500,
 John Levine <[email-masked]> wrote 

> I'm sure there are others, feel free to send suggestions.

Well, some more were mentioned in draft-bortzmeyer-dprive-step-2 some years ago:

1) DANE (used as a signaling tool)

2) "reverse" DNS
3.5.0.0.1.0.0.0.0.0.0.0.0.0.0.0.e.f.a.c.2.4.0.0.8.b.d.0.1.0.0.2.ip6.arpa IN TXT "I do DoT"

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 4 Nov 2019 15:25:55 +0100

> that a server offers ADoT:

I would like also a discussion on whether signaling is 1) good 2)
necessary.

Even if you get a signal, the reality may be out-of-sync with the
signal, for instance because of a problem on the server side (remember
AAAAs published without checking IPv6 connectivity works) or on the
client side (port 853 blocked). So, in any case, the client has to be
ready to encounter a problem and to try a fallback.

So, why not an "happy eyeball" (RFC 8305) approach? Check 53 and 853
more or less in parallel and keep DoT if it works.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Nov 2019 07:12:46 -0800

On Mon, Nov 4, 2019 at 6:26 AM Stephane Bortzmeyer <[email-masked]>
wrote:

> client side (port 853 blocked).

I'm less worried about the latter because I would expect recursive
resolvers to generally be operated by people who are able to establish
their port 853 status.

So, in any case, the client has to be
> more or less in parallel and keep DoT if it works.

Well, this is why I asked about the threat model. If we care about active
attack, then this kind of approach does not work well.

-Ekr

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 4 Nov 2019 16:32:26 +0100

On Mon, Nov 04, 2019 at 07:12:46AM -0800,
 Eric Rescorla <[email-masked]> wrote 
 a message of 96 lines which said:

> resolvers to generally be operated by people who are able to
> establish their port 853 status.

Not all resolvers are big boxes in the central datacenter. I may want
to run a resolver on a small box at home even if my ISP blocks port
853.

> Well, this is why I asked about the threat model. If we care about
> active attack, then this kind of approach does not work well.

I tend to agree with Stephen Farrell here. If we insist on perfect
resistance to active attackers, we may never deploy anything. I would
suggest something more like "probe 853, remember what it was last time
(to warn the sysadmin about a sudden block), may be allow to whitelist
auth servers that must have DoT".

For signaling, my personal preference goes to DANE, anyway.

---

From: "John R Levine" <[email-masked]>
Date: 4 Nov 2019 10:38:40 -0500

> to run a resolver on a small box at home even if my ISP blocks port

I don't think anyone expects port 53 to go away.

> resistance to active attackers, we may never deploy anything.

Same answer, port 853 is additional to port 53.

> For signaling, my personal preference goes to DANE, anyway.

I'll add it to the list.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Nov 2019 08:17:02 -0800

> to run a resolver on a small box at home even if my ISP blocks port

Yes, I didn't say "control" it, but "establish" it. My point is that you
will generally know which state you are in and not need to do an automatic
fallback.

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Mon, 4 Nov 2019 09:54:41 -0800

On 11/4/2019 7:12 AM, Eric Rescorla wrote:
>
>
> On Mon, Nov 4, 2019 at 6:26 AM Stephane Bortzmeyer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      John Levine <[email-masked] <mailto:[email-masked]>> wrote

Note that port 853 is a convention. Servers could trivially run multiple
services over port 443, and demux based on the ALPN. I suppose that if
we see a lot blockage of port 853, servers will just do that -- run on
port 443, demux based on ALPN="DoT"...

-- Christian Huitema

---

From: "John R Levine" <[email-masked]>
Date: 4 Nov 2019 14:55:14 -0500

> https://datatracker.ietf.org/doc/draft-levine-dprive-signal/

Did another version with more possibilities.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Manu Bretelle <[email-masked]>
Date: Mon, 4 Nov 2019 19:13:20 -0800

FYI, I tried to cover some alternatives with their pros/cons during IETF104
DPRIVE meeting:
https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01.pdf

Seems there is a fair intersection with the one available in this draft.

Manu

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 5 Nov 2019 15:52:18 +0000

Very helpful! Some very minor feedback for any potential next version:

- Add reference to draft-bretelle-dprive-dot-for-insecure-delegations-00
- Section 3, 1st para is about auth with secure delegation in conflict with the section title. Perhaps s/Authenticating an insecure delegation/Authentication and describe auth w/secure delegation briefly in a new 3.1. Alternatively, the auth w/secure delegation bit is a tiny section of it's own and what is now S3 becomes S4 with the current section title.

In preparation for IETF-106, we are tracking open Qs for WG discussion at https://github.com/alex-nicat/ietf-dprive-phase2-requirements/issues/20. Feel free to add to that.

Jason

On 11/4/19, 2:56 PM, "dns-privacy on behalf of John R Levine" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,

---

From: Warren Kumari <[email-masked]>
Date: Tue, 5 Nov 2019 11:11:55 -0500

On Mon, Nov 4, 2019 at 12:58 PM Christian Huitema <[email-masked]> wrote:
> On Mon, Nov 4, 2019 at 6:26 AM Stephane Bortzmeyer <[email-masked]> wrote:
>>
> I'm less worried about the latter because I would expect recursive resolvers to generally be operated by people who are able to establish their port 853 status.
>
>
> Note that port 853 is a convention.

Yes -- and that was a conscious choice by the WG; a number of people
always figured that there would be DoT servers running on 443, but
that wasn't something that could be recommended in the document...

W

> Servers could trivially run multiple services over port 443, and demux based on the ALPN. I suppose that if we see a lot blockage of port 853, servers will just do that -- run on port 443, demux based on ALPN="DoT"...
>
> -- Christian Huitema
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2019 13:51:45 -0500

>port 443, demux based on ALPN="DoT"...

If you're going to do that, it's probably easier to have your client
add https headers and do DoH than to add a DoT switch to the ALPN
code in your web server.

R's,
John

---

From: Christian Huitema <[email-masked]>
Date: Tue, 5 Nov 2019 22:46:05 -0800

> add https headers and do DoH than to add a DoT switch to the ALPN

It depends on the server. I am currently testing a QUIC server that can
support multiple ALPN. That was pretty useful during the development of
HTTP3, because the server could support both HTTP 1.0 and HTTP 3 over
QUIC. I am designing the support for DNS over QUIC in that code, and I
plan to use the same code for receiving DNS requests natively in QUIC
streams or through HTTP POST operations.

On the client side the code is markedly simpler without the HTTP overhead.

-- Christian Huitema