Stephane,
On 14/02/2019 09.05, Stephane Bortzmeyer wrote:
On Wed, Feb 13, 2019 at 10:51:00PM +0100,
Vladimír Čunát <vladimir.cunat+i...@nic.cz> 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
