Re: [DNSOP] Multiplexing DNS & HTTP over TLS (was: extension of DoH to authoritative servers)
On 14 Feb 2019, at 05:03, Shane Kerr wrote: > On 14/02/2019 09.05, Stephane Bortzmeyer wrote: >> On Wed, Feb 13, 2019 at 10:51:00PM +0100, >> Vladimír Čunát wrote >> a message of 118 lines which said: >>> Technically you can run DoT on whatever port you like. >>> 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. >> 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. > > 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?". 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Multiplexing DNS & HTTP over TLS (was: extension of DoH to authoritative servers)
Stephane,
On 14/02/2019 09.05, Stephane Bortzmeyer wrote:
On Wed, Feb 13, 2019 at 10:51:00PM +0100,
Vladimír Čunát wrote
a message of 118 lines which said:
Technically you can run DoT on whatever port you like.
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.
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.
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
