On 4/27/2017 12:13 PM, [email protected] wrote: > 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? Yes, very much. You would use the same certificate for all applications. This is probably OK in many cases. In the cases where that doesn't work, well, don't mix them on the same address and port.
Of course, if I wanted to play devil's advocate, I would point out that the proposed scheme uses the same port for different applications, put results in separate connections for each application. Unless we do something really smart and difficult, the different applications will have somewhat different traffic patterns. The adversaries will be able to recognize that, and may then start some counter measures. It might be more robust to mix the two applications on the same TCP/TLS connection. If application messages are interleaved, traffic analysis becomes significantly harder. That the approach proposed in https://datatracker.ietf.org/doc/draft-hoffman-dns-in-existing-http2/, or in https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/. We are really seeing many flowers blooming in this space... -- Christian Huitema _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
