No, the network observer can observe which clients are offering that protocol as one of a set of options -- selection happens server-side. In TLS 1.3, the selection is part of the EncryptedExtensions, no? Which means an observer can tell that the client offers it, but can't tell whether the server is selecting it at any given time. (Without making the same offer to the server and seeing what it chooses for them, at least.)
As Martin says, if you can get a broad set of clients to start offering it all the time, a network controller would have to kill a lot of connections to be sure they didn't let DNS traffic out. (Of course, if major networks start killing connections with this ALPN token, major implementations would probably find themselves having to implement a fallback, and you haven't won.) My other major issue with your approach is something we learned while prototyping h2c: Looking at the content of a message and dynamically swapping out parsers takes a lot of investment to do performantly. You can bound it by only looking at the beginning of the stream, as you do, but it still hurts. If you want to do this transparently inside of HTTP without looking different on the outside, define an HTTP/2 extension for tunneling DNS. Unknown frame types and settings MUST be ignored -- the client can start shipping DNS queries on stream 0 speculatively and have them ignored if the server doesn't speak your extension, or wait to see if the server's SETTINGS frame indicates that it supports the extension (after 1 RTT), both without any loss of compatibility or performance (other than extra bytes). It doesn't get you HTTP/1.x compatibility, but I'm dubious anything you do within that can be done performantly nor is it a long-term pool to hide in. -----Original Message----- From: Daniel Kahn Gillmor [mailto:[email protected]] Sent: Wednesday, May 3, 2017 5:44 PM To: Martin Thomson <[email protected]>; Mike Bishop <[email protected]> Cc: Patrick McManus <[email protected]>; HTTP Working Group <[email protected]>; DNS Privacy Working Group <[email protected]> Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] On Thu 2017-05-04 10:21:20 +1000, Martin Thomson wrote: > On 4 May 2017 at 10:14, Mike Bishop <[email protected]> wrote: >> It's ALPN. At first blush, I would pick a different ALPN token for >> h2+DNS and define it as a new, derivative protocol. > > For DKG to realize his goal, every client would have to offer that > label. That's not impossible, nor does it make it a bad choice, but > you have to realize that this isn't as good an outcome. if you're going to define an ALPN label, you might as well just pick "dns" and then do straight DNS-over-TLS with it (no need for in-stream demuxing). The problem with this approach is that the network monitor can observe which clients are picking "dns" and which ones are picking "http/1.1", which puts you back in the position where the network adversary can trivially hobble DNS-over-TLS requests while permitting HTTPS. I address this in the draft section "Why not ALPN?" -- if anyone thinks the text there could be improved, i'd be happy to hear suggestions for how to change it. All the best, --dkg _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
