Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener

2017-05-18 Thread Daniel Kahn Gillmor
Thanks to everyone for their useful feedback and commentary. I've just uploaded draft-dkg-dprive-demux-dns-http-03, which attempts to include the insights that people have shared here. Most significantly, it drastically tightens the scope of the draft by focusing on HTTP/1.x only and explicitly

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-08 Thread Mark Nottingham
> On 9 May 2017, at 2:29 pm, Ilari Liusvaara wrote: > > On Tue, May 09, 2017 at 11:20:30AM +1000, Mark Nottingham wrote: >> Hey DKG, >> >> Throwing my .02 in, although it's similar to what you've heard from >> others upthread -- >> >> I wouldn't do this for h1; it'll

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-08 Thread Mark Nottingham
Hey DKG, Throwing my .02 in, although it's similar to what you've heard from others upthread -- I wouldn't do this for h1; it'll be an interop nightmare. H2 gives you the properties you want and the implementation / testing burden is much more realistic. For H2, I wouldn't use an ALPN token;

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-05 Thread Alex Rousskov
On 05/03/2017 06:38 PM, Daniel Kahn Gillmor wrote: > On Wed 2017-05-03 17:34:47 -0600, Alex Rousskov wrote: >> Think of the HTTP proxies, not just origin servers. > Here's a few things i think you might be saying: > > 0) A DNS client shouldn't expect this mechanism to work in the clear >

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-04 Thread Mike Bishop
Even on the same connection as HTTP traffic, this would work -- it just wouldn't be flow-controlled beyond TCP, while the HTTP/2 streams would be. -Original Message- From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] Sent: Thursday, May 4, 2017 2:42 AM To: Daniel Kahn Gillmor

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-04 Thread Ilari Liusvaara
On Wed, May 03, 2017 at 07:50:00PM -0400, Daniel Kahn Gillmor wrote: > > Sometimes the backends behind these proxies have to accept traffic directly > > too, and they fingerprint the first few bytes to determine whether it's a > > direct HTTP connection, or a proxied request. I haven't thought

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-04 Thread Stefan Eissing
> Am 04.05.2017 um 04:53 schrieb Mike Bishop : > > 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

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Mike Bishop
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

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Martin Thomson
On 4 May 2017 at 11:26, Daniel Kahn Gillmor wrote: > hm, it sounds like that won't work for h2, given Patrick's point that h2 > isn't client-speaks-first. Right? If we tried to do something like > "h2|dns", it seems like it would introduce a potential latency hit for >

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Daniel Kahn Gillmor
On Thu 2017-05-04 11:11:59 +1000, Martin Thomson wrote: > On 4 May 2017 at 10:43, Daniel Kahn Gillmor wrote: >> 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

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Daniel Kahn Gillmor
On Wed 2017-05-03 20:49:22 -0400, Patrick McManus wrote: > the http/1 share of https:// traffic is dwindling fast. Its down to about > 1/3 of https for me. So if you're looking to hide in a big pool, that's a > shrinking segment. 1/3 of https traffic is still huge collateral damage to inflict, if

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Martin Thomson
On 4 May 2017 at 10:43, Daniel Kahn Gillmor wrote: > 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. Mike is suggesting that you define one that is "http +

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Daniel Kahn Gillmor
On Wed 2017-05-03 20:37:21 -0400, Patrick McManus wrote: >> is the draft you and Paul are working on different than >> ietf-dnsop-dns-wireformat-http ? Can they be reconciled? > > its a superset of that -more aligned with HTTP than that draft, but it can > also carry wireformat. > > your work

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Daniel Kahn Gillmor
On Thu 2017-05-04 10:21:20 +1000, Martin Thomson wrote: > On 4 May 2017 at 10:14, Mike Bishop 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

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Daniel Kahn Gillmor
Hi Alex-- On Wed 2017-05-03 17:34:47 -0600, Alex Rousskov wrote: > On 05/03/2017 05:17 PM, Daniel Kahn Gillmor wrote: >> The idea of the demuxing stage is that a server that opts into this would >> put the demuxing *before* the HTTP/1 server implementation gets access >> to the data. > > Think of

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Martin Thomson
On 4 May 2017 at 10:14, Mike Bishop 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,

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Mike Bishop
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:d...@fifthhorseman.net] Sent: Wednesday, May 3, 2017 4:22 PM To: Patrick McManus ; Patrick

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Daniel Kahn Gillmor
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

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Daniel Kahn Gillmor
On Wed 2017-05-03 12:35:52 -0700, Roy T. Fielding wrote: > I see no reason to suggest that spraying DNS on an HTTP connection would > be interoperable. HTTP/1.x has a tradition (good or bad) of allowing > robust parsing of bad messages, which means no analysis of DNS uniqueness > can guard

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Daniel Kahn Gillmor
Hi Patrick-- On Wed 2017-05-03 14:57:24 -0400, Patrick McManus wrote: > My initial response is that legacy HTTP/1 implementations will sink you by > scanning for stuff that looks like HTTP in your stream - even if the > leading bytes don't match the production those RFCs required (and HTTP/1.0 >

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Roy T. Fielding
> On May 3, 2017, at 11:33 AM, Joe Touch wrote: > > Hi, all, > > FWIW...speaking from the experience I have leading the IANA ports expert > review team and developing BCP165 (RFCs 6335 and RFC7605): > > On 5/3/2017 11:15 AM, Daniel Kahn Gillmor wrote: >> And Joe Touch pointed

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Colm MacCárthaigh
On Wed, May 3, 2017 at 11:15 AM, Daniel Kahn Gillmor wrote: > Hi HTTP folks-- > > I've just pushed a revision to a recent individual submission about a > technique for hiding DNS traffic that makes use of HTTP: > >

[dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

2017-05-03 Thread Daniel Kahn Gillmor
Hi HTTP folks-- I've just pushed a revision to a recent individual submission about a technique for hiding DNS traffic that makes use of HTTP: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/ It describes how a TLS server can offer both HTTPS and DNS-over-TLS on the same

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-28 Thread Hugo Connery
On Fri, 2017-04-28 at 23:37 +0300, Ilari Liusvaara wrote: > On Fri, Apr 28, 2017 at 12:44:19PM -0700, Joe Touch wrote: > > > > The key, however, is that this proposal is really redefining HTTP > > ports > > 80 and 443 (if that's the direction you go), and you need to get > > consensus on that.

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-28 Thread Hugo Connery
On Fri, 2017-04-28 at 16:25 -0700, Joe Touch wrote: > > On Apr 28, 2017, at 4:21 PM, Mark Andrews wrote: > > > > Writing a draft is how we propose extensions. > > The IANA considerations at least need to make that clear. [snip]. +1 "Writing a draft ...".   The multi-decade

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-28 Thread Joe Touch
> On Apr 28, 2017, at 4:21 PM, Mark Andrews wrote: > > Writing a draft is how we propose extensions. The IANA considerations at least need to make that clear. It would help to have this update the HTTP RFCs and be explicit about that goal from the abstract onwards too. Joe

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-28 Thread Mark Andrews
In message , Joe Touch writes: > Hugo, > > > On 4/28/2017 12:57 PM, Hugo Connery wrote: > > ... > >> But using any existing ports for new behaviors is simply not your > >> right. > >> ... > > I could not more vehemently disagree. > > > > 1) DKG is

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-28 Thread Joe Touch
Hugo, On 4/28/2017 12:57 PM, Hugo Connery wrote: > ... >> But using any existing ports for new behaviors is simply not your >> right. >> ... > I could not more vehemently disagree. > > 1) DKG is publishing an idea to the community, not taking over > anything. That idea encourages others to squat

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-28 Thread Joe Touch
On 4/28/2017 1:37 PM, Ilari Liusvaara wrote: >> The key, however, is that this proposal is really redefining HTTP ports >> 80 and 443 (if that's the direction you go), and you need to get >> consensus on that. It's not enough to simply say "we want to do it and >> it works as currently specd". >

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-28 Thread Joe Touch
Hi, Daniel, On 4/28/2017 12:14 AM, Daniel Kahn Gillmor wrote: > In particular, the approach i've described in the draft only works for > client-speaks-first, stream-based protocols. I don't think you can assert that it works except where you have checked, and only for the *current* definition of

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-28 Thread Ray Bellis
On 28/04/2017 08:42, Daniel Kahn Gillmor wrote: > But does the non-predictability requirement hold in stream-based DNS, > where the establishment of the stream itself provides at least as good > protection against spoofed responses? If it holds in cleartext > stream-based DNS, does it also hold

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-28 Thread Daniel Kahn Gillmor
Hi Joe-- Thanks for the feedback! On Thu 2017-04-27 10:13:54 -0700, Joe Touch wrote: > Speaking as an IANA ports team reviewer: > > IMO this document needs to UPDATE the HTTPS specification. The draft isn't strictly about HTTPS, though that context is certainly a prime motivating factor. It's

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-27 Thread Shumon Huque
On Thu, Apr 27, 2017 at 9:21 PM, Paul Hoffman wrote: > On 27 Apr 2017, at 17:51, Shumon Huque wrote: > > Perhaps we should revisit the decision not to encrypt the ALPN >> extension (NPN redux?). >> > > The term "we" is probably not appropriate here. It was not this WG that

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-27 Thread Joe Touch
On 4/27/2017 12:01 PM, Joe Touch wrote: > Hi, Christina, > > On 4/27/2017 11:51 AM, Christian Huitema wrote: PS - my sincere apologies to Christian. (spellcheck is evil ;-( Joe ___ dns-privacy mailing list dns-privacy@ietf.org

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-27 Thread Marc.Mosko
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?

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-27 Thread Joe Touch
Hi, Christina, On 4/27/2017 11:51 AM, Christian Huitema wrote: > 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 This can be done for a new service

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-27 Thread Christian Huitema
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"

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-27 Thread Hugo Maxwell Connery
.org Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] Hi, all, Speaking as an IANA ports team reviewer: IMO this document needs to UPDATE the HTTPS specification. Otherwise, it's basically encoura

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-27 Thread Tony Finch
Section 3.2.2 HTTP/1 Is there a SP missing between the request-target and the HTTP-version in the diagram of the shortest possible request? Section 4.3 Opcode / 4.6 ANCOUNT NSCOUNT Do you want to support UPDATE? If not it should probably be ruled out up front, since it changes some of the

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-27 Thread Petr Špaček
On 27.4.2017 02:43, Daniel Kahn Gillmor wrote: > Hi Jan-- > > On Wed 2017-04-26 11:05:33 +0200, Jan Včelák wrote: >> thank you for writing this down. The draft is great. And it's awesome >> that it's accompanied with an actual running code. > > thanks! and thanks for the quick review :) > >>

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

2017-04-26 Thread Daniel Kahn Gillmor
Hi Jan-- On Wed 2017-04-26 11:05:33 +0200, Jan Včelák wrote: > thank you for writing this down. The draft is great. And it's awesome > that it's accompanied with an actual running code. thanks! and thanks for the quick review :) > A have just a few notes after reading the draft for the first