It's ALPN. At first blush, I would pick a different ALPN token for h2+DNS and define it as a new, derivative protocol.
-----Original Message----- From: Daniel Kahn Gillmor [mailto:[email protected]] Sent: Wednesday, May 3, 2017 4:22 PM To: Patrick McManus <[email protected]>; Patrick McManus <[email protected]> Cc: 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 Wed 2017-05-03 15:13:43 -0400, Patrick McManus wrote: > I forgot to mention another potential challenge with the demux > approach - > h2 is not client send first.. typically both sides send SETTINGS > simultaneously.. and its important to the server not to hold those > back .5RTT as it can contain a bunch of configuration information > (buffer sizing, levels of parallelism, extension negotiation, etc..) > that it wants the client to start honoring asap. (Whether this is > actually simultaneous boils down to which flavor of tls handshake is > done.) Ah! Thanks for this heads-up. That's definitely an interesting wrinkle. How does this interact with HTTP/1 clients connecting to the service? or is it only possible to do this because of the negotiated ALPN? If so, perhaps the demuxing needs to be done only when not sending an alpn of "h2", and the draft can drop the HTTP/2 section. What do you think? --dkg _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
