Subject: Re: [DNSOP] extension of DoH to authoritative servers

From: "Henderson, Karl" <[email-masked]>
Date: Wed, 13 Feb 2019 21:45:26 +0000

Couldn’t DoT also run over port 443 just like DOH -– similar to what’s been proposed in this draft?: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 13 Feb 2019 22:51:00 +0100

On 2/13/19 10:45 PM, Henderson, Karl wrote:
>
> Couldn’t DoT also run over port 443 just like DOH -– similar to what’s
> been proposed in this
> draft?: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/
>
Technically you can run DoT on whatever port you like.  I believe the
port number argument and non-recognizability from https are mainly red
herrings when comparing DoH with DoT.  And there are more, as the two
protocols share almost all properties.

Example: with knot-resolver it's easy - you just add @443, either on
side of server and/or on the side of forwarding over TLS.

--Vladimir

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Feb 2019 09:05:08 +0100

On Wed, Feb 13, 2019 at 10:51:00PM +0100,
 Vladimír Čunát <[email-masked]> wrote 
 a message of 118 lines which said:

> Technically you can run DoT on whatever port you like.

> side of server and/or on the side of forwarding over TLS.

The problem is that you cannot then share this port with HTTPS
services (the dkg draft on demultiplexing was abandoned, apparently
because it doesn't work). In a world of scarce IPv4 public addresses,
this is a serious problem.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 14 Feb 2019 11:03:31 +0100

Stephane,

> this is a serious problem.

Interesting. I know that the multi-purpose usage smelled bad but I 
didn't know that it didn't work.

Is there a write-up on this?

Thinking about it naively, a demultiplexer really only needs to say "is 
there a non-ASCII character in the first 2 or 3 bytes of a TLS session?".

An HTTP message always starts with some ASCII letters, like "GET" or 
"HEAD". In contrast, a DNS over TLS client will start with a message 
length encoded in 2 bytes. Since in practice queries will be less than 
256 bytes and therefore not start out with an ASCII letter (like 'G' or 
'H'). Actually this would require a client message of 16705 bytes to 
required that *both* the first two bytes are ASCII letters:

 >>> (ord('A') << 8) | ord('A')
16705

Since this is only required for the *first* DNS query on a TLS session, 
a client could always send a short query as the first one to avoid this 
issue. (I'm not sure how this would impact known-text analysis, but 
presumably TLS is resistant to this sort of cryptanalysis since HTTP 
almost always starts with the same few bytes.)

Even if the two-byte length results in ASCII letters, the client can 
sacrifice 1 bit of the message ID and ensure that it always has 
non-ASCII values, so the 3rd byte will always be non-ASCII and therefore 
not a valid HTTP command. So if it was really necessary to handle the 
case of queries of length 16705 or greater for the first query on a 
session, a client could always limit its message ID space to 32768 
possible values, which should be fine on a stateful connection where 
message ID is only used to match out-of-order answers.

I admit the issue of hand-off from a demultiplexer to a DNS server or 
HTTP server might be non-trivial, but in principle it should be possible.

Or is the issue to do with TLS itself? I don't know enough about SNI to 
know if there may be some reason why HTTP-based TLS could be different 
from DNS-based TLS, but I suppose it is possible. 🤔

Cheers,

--
Shane

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 14 Feb 2019 12:51:40 +0100

> this is a serious problem.

You can still multiplex based on SNI sent by the client.  HTTPS clients
surely send it commonly.  DoT clients perhaps not so often, but that's
just an implementation detail (which I was fixing in the past few weeks
in knot-resolver, incidentally).

I'm not sure how easy SNI-based multiplexing is to configure with
nowadays software, but I believe I've heard of some such setup with
nginx.  And I don't have any idea whether SNI encryption would interfere
with that, but I hope not.  ESNI will be a key part of DNS privacy,
though mainly for the non-DNS traffic.

---

From: Bjørn Mork <[email-masked]>
Date: Thu, 14 Feb 2019 13:11:55 +0100

> in knot-resolver, incidentally).

My understanding of the reference to BCP195 from
https://tools.ietf.org/html/rfc7858#section-3.2
is that SNI support is required for all DoT implementations.

> though mainly for the non-DNS traffic.

It's simple to do with haproxy at least:
https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/

...which incidentally also can be used to support DoT with *any* DNS
server as backend.

Bjørn

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Feb 2019 07:34:10 -0500

On 14 Feb 2019, at 05:03, Shane Kerr <[email-masked]> wrote:

> Interesting. I know that the multi-purpose usage smelled bad but I didn't know that it didn't work.
> 
> Thinking about it naively, a demultiplexer really only needs to say "is there a non-ASCII character in the first 2 or 3 bytes of a TLS session?".

I think we can consider explicit payload identification an important feature of successful protocols. Encapsulating layers need to signal key information about the nature of their contents explicitly, or you wind up with the kind of nonsense that we saw in flow-hashing in MPLS where expected network behaviours depended on which transport protocol or address family you happen to be using way up the stack, and ugly hacks abound.

Your thought-algorithm above might be ok for discriminating between DoT and HTTPS (although I think anything that depends on a condition like "non-ASCII" is highly suspect :-) but what about other protocols, current and imagined future, that might use TLS as an encapsulating protocol, e.g. to address similar privacy concerns? This doesn't seem like a problem that is particularly theoretical.

Running whatever protocol I like on whatever port I like is fine so long as I am informed about the nature of the communication (e.g. I am involved in the decisions at both ends; I configure my ssh client and my ssh server both to use 53/tcp for my own special reasons so the use of that port is understood and doesn't need to be negotiated). In the DNS, one endpoint often has no prior knowledge of even the existence of the other endpoint. Asking one or both sides to make inferences about the nature of a session without explicit signalling does not seem robust.

Joe

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 14 Feb 2019 14:00:32 +0100

> Thinking about it naively, a demultiplexer really only needs to say "is there a 
> non-ASCII character in the first 2 or 3 bytes of a TLS session?".
> 
>

Hi,

please think of HTTP/2, which is a binary protocol (although I don't know what 
the first bytes are). But I guess ALPN (RFC 7301) would do the trick.

Regards,

Klaus

---

From: Shane Kerr <[email-masked]>
Date: Thu, 14 Feb 2019 14:23:59 +0100

Klaus,

On 14/02/2019 14.00, Klaus Malorny wrote:
>> Thinking about it naively, a demultiplexer really only needs to say 
>> "is there a non-ASCII character in the first 2 or 3 bytes of a TLS 
>> session?".
>>
> please think of HTTP/2, which is a binary protocol (although I don't 
> know what the first bytes are). But I guess ALPN (RFC 7301) would do the 
> trick.

I think that HTTP/2 preserves the initial handshake of HTTP/1.1.

But looking at ALPN, it was designed for exactly this the multiplexing 
use case. In principle all that would be needed is adding an identifier 
to the ALPN protocol IDs:

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

It would also address Joe's concerns about other protocols.

Maybe creating an ALPN protocol ID for DNS-over-TLS is something for the 
DPRIVE working group? 🤔

Cheers,

--
Shane

---

From: Tony Finch <[email-masked]>
Date: Thu, 14 Feb 2019 13:46:02 +0000

> ...which incidentally also can be used to support DoT with *any* DNS

I'm using nginx as my DoT and DoH front-end proxy
(https://github.com/fanf2/doh101/) and it looks
like I need to add ssl_preread support to get the SNI
https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

I'm only really interested in logging it to see what the clients think
they are talking to - they are almost all Androids doing opportunistic
DoT.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Bailey: Southwest becoming cyclonic, mainly south 5 to 7, occasionally gale 8.
High becoming rough or very rough. Occasional rain. Moderate or poor.

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2019 12:22:37 -0500

>I think that HTTP/2 preserves the initial handshake of HTTP/1.1.

Seems to me you could make it work using SNI, so long as the name you
use for the web and DNS servers are different.  I realize this makes
it more sniffable, but maybe that's less bad than some of the
alternatives.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 15 Feb 2019 16:21:50 -0500

> Maybe creating an ALPN protocol ID for DNS-over-TLS is something for the

https://mailarchive.ietf.org/arch/browse/dns-privacy/?q=ALPN

https://tools.ietf.org/html/draft-hoffman-dprive-dns-tls-alpn-00

https://www.ietf.org/archive/id/draft-dkg-dprive-demux-dns-http-03.txt

I'd encourage folk to go read the archive (and, again, there is a WG for
this -- https://datatracker.ietf.org/wg/dprive/about/ ).

W

>
> Cheers,
>
> --
> Shane
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

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