On 4/27/2017 10:48 AM, Joe Touch wrote: > ... > In brief: > Ports serve two purposes - demultiplexing IDs to enable multiple > connections to a host with a single IP address, and (for first-contact > from client to server) to indicate the default service that receives > incoming "first contact" requests. > > You could certainly define a new service that combines HTTPS and DNS on > a single port. Note that RFC6335 and RFC7605 both recommend against > creating new ports for existing services, but it *might* be arguable > that the combined service is somehow uniquely distinct (that would need > to be successfully argued, though).
Well, things do change. The most interesting thing that we did observe is the generalized used of TLS. The stack used to be IP/TCP/App, and in that case you really need to demux at the TCP layer, and you can do that using ports. The stack that we do have now is IP/TCP/TLS/App, or IP/Quic/TLS/App. We could still demux at the TCP layer, but we could also demux at the TLS layer. As DKG points out, demuxing at the TLS layer does hide some of the metadata, and thus provides better privacy and resistance to censorship than demuxing on the clear text TCP port. Of course, one only gets the privacy benefits if the TLS demuxing is not based on clear text fields like the SNI or the ALPN. DKG proposes an heuristic, based on the observation that the first bytes of application data are enough to differentiate HTTP and DNS. Heuristics like these have the advantage of being easily deployed. They do have the inconvenient of affecting the long term evolution of the application protocols. We may want to look at a robust long term alternative. HTTP2 actually took a step in that direction. This is specified in section 3.5 of RFC 7540. "Each endpoint is required to send a connection preface as a final confirmation of the protocol in use and to establish the initial settings for the HTTP/2 connection. The client and server each send a different connection preface." The spec goes on to specify a 24 byte string, corresponding to the ASCII value "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n", which the server acknowledges by sending a "SETTINGS" frame. So maybe we could build on that, and let application register their specific 24 bytes string, allowing for demux on top of TLS. That would define an organized process. -- Christian Huitema _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
