[DNSOP] Multiplexing DNS & HTTP over TLS (was: extension of DoH to authoritative servers)

[Shane Kerr <[e-mail]>]

Stephane,

On 14/02/2019 09.05, Stephane Bortzmeyer wrote:
> On Wed, Feb 13, 2019 at 10:51:00PM +0100,
>   Vladimír Čunát <[e-mail]> 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