I think I’m missing something about this proposal, at least in the case of a general demux protocol. If you detach TLS from a specific application context, who provides the certificates and evaluates the trust anchors? If you don’t have a traffic secret, how do you hide the demux signaling? It seems like having a general purpose TLS demux would require delegating all that to some other process including the DH exchange?
I can see how, as draft draft-dkg-dprive-demux-dns-http-00 puts it, a special terminator might offer two protocols of DNS and HTTP, but those are both being offered by the same application that share the same TLS credentials, yes? Thanks, Marc > On Apr 27, 2017, at 11:51 AM, Christian Huitema <[email protected]> wrote: > > > > 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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
