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

[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
> made that decision: it was the TLS WG, after multiple threads with (I
> believe) hundreds of messages.


Yeah, I should have been more precise. By "we", I was referring to TLS or
perhaps the larger IETF community (and not DPRIVE) ..

-- 
Shumon Huque
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[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
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[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?  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?

Thanks,
Marc

> On Apr 27, 2017, at 11:51 AM, Christian Huitema  wrote:
> 
> 
> 
> 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" requests.
>> 
>> You could certainly define a new service that combines HTTPS and DNS on
>> a single port. Note that RFC6335 and RFC7605 both recommend against
>> creating new ports for existing services, but it *might* be arguable
>> that the combined service is somehow uniquely distinct (that would need
>> to be successfully argued, though).
> 
> Well, things do change. The most interesting thing that we did observe
> is the generalized used of TLS. The stack used to be IP/TCP/App, and in
> that case you really need to demux at the TCP layer, and you can do that
> using ports. The stack that we do have now is IP/TCP/TLS/App, or
> IP/Quic/TLS/App. We could still demux at the TCP layer, but we could
> also demux at the TLS layer. As DKG points out, demuxing at the TLS
> layer does hide some of the metadata, and thus provides better privacy
> and resistance to censorship than demuxing on the clear text TCP port.
> 
> Of course, one only gets the privacy benefits if the TLS demuxing is not
> based on clear text fields like the SNI or the ALPN. DKG proposes an
> heuristic, based on the observation that the first bytes of application
> data are enough to differentiate HTTP and DNS. Heuristics like these
> have the advantage of being easily deployed. They do have the
> inconvenient of affecting the long term evolution of the application
> protocols. We may want to look at a robust long term alternative.
> 
> HTTP2 actually took a step in that direction. This is specified in
> section 3.5 of RFC 7540. "Each endpoint is required to send a connection
> preface as a final confirmation of the protocol in use and to establish
> the initial settings for the HTTP/2 connection.  The client and server
> each send a different connection preface." The spec goes on to specify a
> 24 byte string, corresponding to the ASCII value "PRI *
> HTTP/2.0\r\n\r\nSM\r\n\r\n", which the server acknowledges by sending a
> "SETTINGS" frame.
> 
> 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
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[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 to be defined, which then might
qualify for a new IANA for a port assignment.

AFAICT, no one can redefine any existing service, even ones that use
TLS, this way, though.

I'm not sure whether it would be a good idea, though - my view is that
this just serves to push port demuxing - which already exists outside
TLS - inside TLS.

Joe

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[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" requests.
>
> You could certainly define a new service that combines HTTPS and DNS on
> a single port. Note that RFC6335 and RFC7605 both recommend against
> creating new ports for existing services, but it *might* be arguable
> that the combined service is somehow uniquely distinct (that would need
> to be successfully argued, though).

Well, things do change. The most interesting thing that we did observe
is the generalized used of TLS. The stack used to be IP/TCP/App, and in
that case you really need to demux at the TCP layer, and you can do that
using ports. The stack that we do have now is IP/TCP/TLS/App, or
IP/Quic/TLS/App. We could still demux at the TCP layer, but we could
also demux at the TLS layer. As DKG points out, demuxing at the TLS
layer does hide some of the metadata, and thus provides better privacy
and resistance to censorship than demuxing on the clear text TCP port.

Of course, one only gets the privacy benefits if the TLS demuxing is not
based on clear text fields like the SNI or the ALPN. DKG proposes an
heuristic, based on the observation that the first bytes of application
data are enough to differentiate HTTP and DNS. Heuristics like these
have the advantage of being easily deployed. They do have the
inconvenient of affecting the long term evolution of the application
protocols. We may want to look at a robust long term alternative.

HTTP2 actually took a step in that direction. This is specified in
section 3.5 of RFC 7540. "Each endpoint is required to send a connection
preface as a final confirmation of the protocol in use and to establish
the initial settings for the HTTP/2 connection.  The client and server
each send a different connection preface." The spec goes on to specify a
24 byte string, corresponding to the ASCII value "PRI *
HTTP/2.0\r\n\r\nSM\r\n\r\n", which the server acknowledges by sending a
"SETTINGS" frame.

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


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Hugo Maxwell Connery]

Hi all,

This is the argument that I expected; single port allocation looks
clean, and enables "simple" delivery of processing resources.

That's why we created ports, no?  (please flame here, I have no
idea about this historical claim).

The underlying question raised by this lovely proposition is:

  Was that such a great idea in the first place, now that we know
  that surveillance is **what happens on the internet**.

We need the tech community to re-evaluate assumptions based
on what has been learned since RFC7258.

I do not suggest that DKG's suggestion is the answer, but I suggest
that it is worth consideration, and more importantly, the concepts 
behind it need considering.

Should we mandate that all future protocols are "demuxible" from
all previous?

For me, I say "looks like a good idea" (stream based over TLS).  

Bring on the discussion.

Regards,
  Hugo Connery
--
Head of IT, DTU Environment, http://www.env.dtu.dk

From: dns-privacy [dns-privacy-boun...@ietf.org] on behalf of Joe Touch 
[to...@isi.edu]
Sent: Thursday, 27 April 2017 19:13
To: Daniel Kahn Gillmor; Jan Včelák
Cc: dns-privacy@ietf.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 encouraging squatting on port 443 TCP, which
is inappropriate.

Keep in mind that any bit pattern that you *think* differentiates DNS
from HTTPS is not yours to define - it is the purview of HTTPS to define
or delegate in any way they see fit.

You can certainly ask IANA for a new port on which to run both HTTPS and
DNS, but it is inappropriate to change port 443 without coordination.

Joe


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[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 analysis (though not the result,
since octet 5 will be zero for DNS).

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Thames, Dover, Wight, Portland, Plymouth: North or northwest, backing west for
a time, 4 or 5, decreasing 3 at times. Slight or moderate. Showers, then rain
for a time except in Plymouth. Good, occasionally moderate.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[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 :)
> 
>> A have just a few notes after reading the draft for the first time:
>> - For the sake of simplicity, I would suggest dropping the part about
>> HTTP/0.9. I don't think it's worth the effort keeping it supported.
> 
> That would definitely make the document much simpler :) I suppose i
> should float this by the HTTP community, to see whether they agree that
> it's ok to drop HTTP/0.9.
> 
>> - The Section 3 (Overview of initial octets) is a little bit chaotic
>> and scattered. Maybe it would be more readable if you just provided
>> pointers to specification of the protocols without providing much
>> details, then shown the initial octets (or headers) side by side
>> without analysing the content, and in the end walked by the bytes from
>> the beginning while discussing the values.
> 
> I understand what you're saying, i'm not sure how to do this exactly.
> With DNS, the fields are fixed size and have fixed meaning, but with
> HTTP, there's an abstract grammar.  So they don't just "line up" side by
> side, as it were.
> 
> I can certainly remove the copied text and just leave pointers to other
> documents, but that seems like it effectively asks the reader to do a
> bunch of pointer chasing when i've already done the pointer-chasing for
> them.

Let me state that I like current version with copied text. For me it is
really easier to follow than jumping between documents.

Petr Špaček  @  CZ.NIC

> 
> Any concrete suggestions for how to improve it?  It's maintained in
> markdown at https://gitlab.com/dkg/hddemux and i welcome merge requests
> or patches!
> 
>> - I love how simple the algorithm is in the end. And the proof is
>> great.
> 
> I'm glad you like it too -- i'm happy that it seems possible to be
> strictly confident in the demuxing.
> 
>   --dkg

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy