On 14 Feb 2019, at 05:03, Shane Kerr <sh...@time-travellers.org> wrote:
> 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?". 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
