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
> 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
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;
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
>
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
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
> 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
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
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
>
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
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
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 +
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
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
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
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,
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
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
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
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
>
> 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
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:
>
>
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
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.
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
> 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
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
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
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".
>
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
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
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
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
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
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?
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
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"
.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
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
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 :)
>
>>
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
41 matches
Mail list logo