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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 24 Apr 2017 20:48:42 -0400

Hi all--

I just pushed an individual submission that folks in DPRIVE might be
interested in:

   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 port because valid initial messages from each protocol are
always distinguishable by the server.

I have a functional implementation listening on TCP port 443 on
dns.cmrg.net right now, if anyone wants to experiment with it.  Consider
all the possibilities of this terrible layering violation!

Both of these commands works just fine:

    wget -O- https://dns.cmrg.net/

    kdig +tls +tls-ca +tls-hostname=dns.cmrg.net @dns.cmrg.net:443 www.ietf.org

I believe my analysis of DNS and HTTP message framing is correct, but if
that's not the case, i hope someone will helpfully correct me.

Constructive criticism is welcome on-list, and minor editorial cleanup can
be made as merge requests to https://gitlab.com/dkg/hddemux or by
private e-mail.  Please send flames by private e-mail only :)

   --dkg

Subject: New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt
From: [email-masked]
To: "Daniel Kahn Gillmor" <[email-masked]>
Date: Mon, 24 Apr 2017 17:01:37 -0700

A new version of I-D, draft-dkg-dprive-demux-dns-http-00.txt
has been successfully submitted by Daniel Kahn Gillmor and posted to the
IETF repository.

Name:		draft-dkg-dprive-demux-dns-http
Revision:	00
Title:		Demultiplexing Streamed DNS from HTTP
Document date:	2017-04-24
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.org/internet-drafts/draft-dkg-dprive-demux-dns-http-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/
Htmlized:       https://tools.ietf.org/html/draft-dkg-dprive-demux-dns-http-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dkg-dprive-demux-dns-http-00

Abstract:
   DNS over TCP and traditional HTTP are both stream-oriented, client-
   speaks-first protocols.  They can both be run over a stream-based
   security protocol like TLS.  A server accepting a stream-based client
   can distinguish between a valid stream of DNS queries and valid
   stream of HTTP requests by simple observation of the first few octets
   sent by the client.  This can be done without any external
   demultiplexing mechanism like TCP port number or ALPN.

   Implicit multiplexing of the two protocols over a single listening
   port can be useful for obscuring the presence of DNS queries from a
   network observer, which makes it relevant for DNS privacy.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Jan Včelák <[email-masked]>
Date: Wed, 26 Apr 2017 11:05:33 +0200

Hello Daniel,

thank you for writing this down. The draft is great. And it's awesome
that it's accompanied with an actual running code.

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.
- 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 love how simple the algorithm is in the end. And the proof is great.

Cheers,

Jan

On Tue, Apr 25, 2017 at 2:48 AM, Daniel Kahn Gillmor
<[email-masked]> wrote:
> ---------- Forwarded message ----------
> To: Daniel Kahn Gillmor <[email-masked]>
> Cc:
> Bcc:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 26 Apr 2017 20:43:28 -0400

Hi Jan--

> that it's accompanied with an actual running code.

thanks!  and thanks for the quick review :)

> 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 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.

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

I'm glad you like it too -- i'm happy that it seems possible to be
strictly confident in the demuxing.

      --dkg

---

From: Petr Špaček <[email-masked]>
Date: Thu, 27 Apr 2017 09:53:21 +0200

> bunch of pointer chasing when i've already done the pointer-chasing for

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Apr 2017 11:28:15 +0100

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  <[email-masked]>  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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 27 Apr 2017 07:42:42 -0700

> the diagram of the shortest possible request?

whoops, i can't believe i missed that.  thanks!  fixed in git:

    https://gitlab.com/dkg/hddemux/commit/bc88fd5dd65cded1c20a61e55d1e747bba769c1c

> front, since it changes some of the analysis

hm, i don't want to rule out UPDATE, i just hadn't thought about it. --
i can imagine someone wanting to make use of UPDATE over this mechanism,
so it'd be nice to keep it.

I've opened a ticket to track that concern:

    https://gitlab.com/dkg/hddemux/issues/1

>  (though not the result, since octet 5 will be zero for DNS).

Is that guaranteed?  It seems likely in practice, but RFC 2136 says:

   RCODE   Response code - this four bit field is undefined in requests
           and set in responses. 

So it seems conceivable that some client fiddles with these undefined
bits somehow -- they're not required to be zeros, the way the Z section
is :/

the way i'm reading RFC 2136, though, the formats of the four sections
remain the same, so the "Combinations of octets" calculation seems to
still hold, which means the "Proof" section should still hold too, i
think.  Or am i missing something there?

   --dkg

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Apr 2017 10:13:54 -0700

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

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 27 Apr 2017 17:34:27 +0000

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 [[email-masked]] on behalf of Joe Touch [[email-masked]]
Sent: Thursday, 27 April 2017 19:13
To: Daniel Kahn Gillmor; Jan Včelák
Cc: [email-masked]
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,

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Apr 2017 10:48:26 -0700

Hi, Hugo,

> idea about this historical claim).

See RFC7605, which includes a detailed history.

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).

> Should we mandate that all future protocols are "demuxible" from
Well, that's the role ports serve within transport protocols.

And the role that the "protocol" field serves in IPv4, the "next header"
field serves in IPv6, and the "ethertype" field serves in Ethernet...

We always need a way to demux based on protocol, either by a signal from
the lower-level protocol (these fields) or in-band (as in TCPMUX, though
only historic now, or out of band, e.g., mDNS).

However, if you're proposing we do this for ALL services currently
assigned to ports, IMO that's a bad idea - it just serves to push port
demuxing one layer in, which only creates a war of escalation with NATs,
firewalls, and routers - creating an Internet within a flow.

So the question here is - why these two?

Joe

---

From: Christian Huitema <[email-masked]>
Date: Thu, 27 Apr 2017 11:51:36 -0700

On 4/27/2017 10:48 AM, Joe Touch wrote:
> ...

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Apr 2017 12:01:02 -0700

Hi, Christina,

> define an organized process.

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

---

From: <[email-masked]>
Date: Thu, 27 Apr 2017 19:13:46 +0000

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 <[email-masked]> wrote:
> 
> 
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 27 Apr 2017 12:17:30 -0700

> define an organized process.

...which would not work at all for DNS, one of the two protocols being 
discussed here: the first two bytes are *supposed* to be 
non-predictable.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Apr 2017 12:28:49 -0700

> On 4/27/2017 11:51 AM, Christian Huitema wrote:
PS - my sincere apologies to Christian.

(spellcheck is evil ;-(

Joe

---

From: Christian Huitema <[email-masked]>
Date: Thu, 27 Apr 2017 12:32:58 -0700

> 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 sha…
Yes, very much. You would use the same certificate for all applications.
This is probably OK in many cases. In the cases where that doesn't work,
well, don't mix them on the same address and port.

Of course, if I wanted to play devil's advocate, I would point out that
the proposed scheme uses the same port for different applications, put
results in separate connections for each application. Unless we do
something really smart and difficult, the different applications will
have somewhat different traffic patterns. The adversaries will be able
to recognize that, and may then start some counter measures.

It might be more robust to mix the two applications on the same TCP/TLS
connection. If application messages are interleaved, traffic analysis
becomes significantly harder. That the approach proposed in
https://datatracker.ietf.org/doc/draft-hoffman-dns-in-existing-http2/,
or in
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/.
We are really seeing many flowers blooming in this space...

-- Christian Huitema

---

From: Shumon Huque <[email-masked]>
Date: Thu, 27 Apr 2017 20:51:26 -0400

On Thu, Apr 27, 2017 at 2:51 PM, Christian Huitema <[email-masked]>
wrote:

> [...]

Perhaps we should revisit the decision not to encrypt the ALPN
extension (NPN redux?). It seems that might have helped use cases
like these in the more robust manner.

-- 
Shumon Huque

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 27 Apr 2017 18:21:40 -0700

On 27 Apr 2017, at 17:51, Shumon Huque wrote:

> 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.

> It seems that might have helped use cases

Yes, that was the whole point of NPN; in the end it was not persuasive 
to the TLS WG.

--Paul Hoffman

---

From: Shumon Huque <[email-masked]>
Date: Thu, 27 Apr 2017 21:30:54 -0400

> 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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 28 Apr 2017 00:42:22 -0700

> discussed here: the first two bytes are *supposed* to be 

itym (zero-based) octets 2 and 3 are *supposed* to be non-predictable,
since the first two bytes of stream-based DNS are the message length,
which is definitely *not* supposed to be non-predictable.

Out of curiosity, though: is the DNS message ID supposed to be
non-predictable for stream-based DNS as well?

My understanding of the message id is that it was originally intended to
allow servers and clients to identify and associate queries and
responses that already share the same 5-tuple (transport protocol,
source addr, source port, destination addr, destination port).  That
initial intent doesn't require non-predictability, just good bookkeeping
:)

But I know that a subsequent requirement for non-predictability of the
DNS query message ID has arisen as a defense against off-path spoofed
DNS responses: an unpredictable message ID in the query increases the
entropy that an off-path spoofer attacker needs to guess from ~16 bits
(UDP port only) to ~32 bits (UDP port + message ID).

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 for encrypted, streamed DNS, where
the channel itself provides significantly *better* protection against
spoofed responses.

(again, i'm not arguing that exisiting clients *should* change their
message id selection for purposes of this draft; i don't think they need
to!  But i'm wondering if the transport layer(s) we're talking about
actually obviate the typical need for strong message ID randomizaton)

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 27 Apr 2017 23:58:24 -0700

Hi Joe--

Thanks for the feedback!

> 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 about demultiplexing cleartext, streamed DNS from cleartext,
streamed HTTP.  This just happens to mainly be useful in evading network
surveillance and censorship under cover of TLS :)

That said, i definitely agree that the draft needs more input from the
HTTP community.  In particular, if this approach gets deployed widely,
we'd want to ensure that future stream-based versions of HTTP are aware
of this demuxing algorithm and don't create a start-of-stream signature
that the algorithm might confuse with DNS.

But will there be future stream-based versions of HTTP?  afaict,
HTTP-over-QUIC is likely to be the future of HTTP, and that's a place
where this demuxing approach explicitly does not apply (since it's not
stream-based).  So maybe it'll turn out that the draft doesn't scare the
HTTP community much.  We should encourage their review!

I initially sent the doc for discussion here in DPRIVE because DPRIVE
offers one of the primary motivations for the work, and to make sure i
wasn't missing anything crucial from the DNS side. But i'm certainly
planning to bring the document to the attention of HTTP-specific groups.
Perhaps [email-masked] comes next?  I'm open to other suggestions.

> or delegate in any way they see fit.

I hope it's clear from the draft that it's not defining any
differentiating bit pattern.  Rather, it's pointing out that the
existing specifications *already* define necessarily distinguishable bit
patterns.

> DNS, but it is inappropriate to change port 443 without coordination.

This seems unlikely to achieve any useful goal -- existing HTTPS isn't
going to move to a new port, which means traffic on that port would be
suspect to a would-be censor or a pervasive monitor, right?

Joe, as a thought experiment, as an IANA ports reviewer, if both the
HTTP and DNS communities were to decide that some version of draft seems
OK to them, what would you want the IANA Considerations section to look
like?

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 28 Apr 2017 00:14:29 -0700

> Should we mandate that all future protocols are "demuxible" from

fwiw, i'm not prepared to make any kind of statement anywhere near that
grand, and i'd hope that the specific proposal under discussion doesn't
hinge on us having to make such sweeping analysis.  What are "all
previous protocols", for example?  does it need to be demuxable from
tcpmux itself? or what about RFC 862? ;)

In particular, the approach i've described in the draft only works for
client-speaks-first, stream-based protocols.  It doesn't work at all for
server-speaks-first protocols like SMTP or SSH, for example, and it
doesn't address non-stream-based protocols at all.

The proposed approach is situated in the particular historical
circumstance we find the Internet in today.  It'd be great if it wasn't
necessary to consider it (if there were no networks actively hostile to
user privacy and "surprising" ports, for example), and hopefully future
Internet transport protocols can be demuxed at the server in a way that
is opaque to the network operator in the first place, so that problems
like this don't arise.

I'm happy to have the bigger-picture discussion about how to plan for
the future, but i hope this particular draft can be evaluated on its own
merits (or lack thereof), largely independent of that discussion.

    --dkg

---

From: Ray Bellis <[email-masked]>
Date: Fri, 28 Apr 2017 09:15:18 +0100

> the channel itself provides significantly *better* protection against

What if the stream is being unwrapped before it reaches the eventual
destination,  e.g. a hypothetical TLS endpoint that forwards the
received queries over UDP  ?

Who's responsibility is it to make sure those forwarded queries can't be
spoofed?

It's a stretch, I know, but the point is to make us consider how
removing security features might have unintended consequences upstream.

Ray

---

From: Tony Finch <[email-masked]>
Date: Fri, 28 Apr 2017 10:36:07 +0100

Daniel Kahn Gillmor <[email-masked]> wrote:

> Is that guaranteed?

Er, in fact, no. I forgot about the AD and CD flags, so I think in
practice you are likely to see octet 5 values of 0x00 0x10 0x20 0x30

Probably on more solid ground to assume QDCOUNT == 1 :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Wight, Portland: Northwest 4 or 5, becoming variable 4. Smooth or slight.
Showers. Good.

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 08:50:44 -0700

Hi, Daniel,

On 4/28/2017 12:14 AM, Daniel Kahn Gillmor wrote:
> 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 those protocols.

Keep in mind that ports are assigned to current *and all future*
versions of a protocol, so all bets are off the instant you stop
looking. Which means, effectively, that you can never assert that this
works on an existing port assignment UNTIL you coordinate with that
port's assignee, and they confirm that their service will never conflict
with your definition.

That also implies that this service cannot be defined as valid for any
service that isn't already assigned. That would effectively be squatting
on the entire port space.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 08:57:39 -0700

Hi, Daniel,

> that the algorithm might confuse with DNS.

That's the key - you need to know that port 443 and 80 are defined by
HTTP, not this document.

If you want to define a service without any coordination, you certainly
can propose to merge the current definitions of DNS and HTTP/HTTPS and
see whether that qualifies for a port assignment.

But you cannot redefine a port belonging to another party.

...
> existing specifications *already* define necessarily distinguishable bit

That's like saying that I can take your car because you're not currently
in it.

Ports 80 and 443 belong to HTTP/HTTPS. They *own* ***ALL*** current and
future bit patterns on that port.

The same is true for all other current assignments. And all unassigned
or reserved ports (from the assignable ranges) are effectively owned by
IANA until they are assigned.

Under no condition is it appropriate for this or any other document to
define the meaning of a bit pattern on any port **EXCEPT** those
assigned to that service.

> This seems unlikely to achieve any useful goal 
It preserves the integrity of HTTP and HTTPS, and ensures that those
protocols can use whatever bit pattern they want for future variants.

> -- existing HTTPS isn't
All traffic on the Internet is already subject to censorship and
monitoring.  I can't see how you can traverse someone else's link or
router without that possibility, regardless of port.

> OK to them, what would you want the IANA Considerations section to look
IMO, either:

    a) a request for a new assignment (listed as TBD in this document
until assigned; please do not squat on an unassigned port that might be
assigned in the meantime)
or
    b) if you want to redefine an existing service on a currently
assigned port, a clear indication in the doc header, abstract, intro,
content, and IANA sections that this doc updates HTTP or HTTP, or
whatever service you want this to update. (which would require
confirmation by IANA in contact with the current assignee).

Joe

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 28 Apr 2017 09:52:43 -0700

On Fri 2017-04-28 08:57:39 -0700, Joe Touch wrote:
>> -- existing HTTPS isn't going to move to a new port, which means
>> traffic on that port would be suspect to a would-be censor or a
>> pervasive monitor, right?
>

To clarify any miscommunication, i said *suspect* (in the sense of
"suspicious"), not *subject*.  One of the aims of the draft is to make
the two protocols less distinguishable from one another to a network
attacker who might prefer one over the other (and consider the other to
be suspicious).  A new port assignment fails to meet that goal.

Of course users are subject to censorship and monitoring by networks
that they rely on.  This power imbalance between network operator and
user is part of the way that digital transport works.  We can try to
even out this power imbalance by demonstrating mechanisms for the user
to make their traffic indistinguishable from other traffic and opaque to
the network operator -- that way the operator cannot target them for
censorship or surveillance without incurring heavy collateral damage.

The goal of this WG is to provide confidentiality to the DNS querier
against a network attacker.  If every mechanism that we produce can be
identified by a network adversary who wants to violate that
confidentiality, then the adversary can simply kill that traffic,
causing the user to fall back to cleartext DNS or to leave the network
entirely.  This draft is trying to defend against that scenario, which
is why i brought it here first.

Your points are noted, thanks, and i'll branch the discussion and start
talking with the HTTP folks soon.

Regards,

           --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 28 Apr 2017 09:19:14 -0700

> Who's responsibility is it to make sure those forwarded queries can't be

hm, good point.  If the UDP endpoint is spoofable/injectable (e.g. over
an untrusted network) I'd say that the thing converting from a stream to
a UDP stream is at fault -- it doesn't know what assumptions the client
is making about the transport.

> removing security features might have unintended consequences upstream.

yep, if we decide to explicitly discourage non-predictability for the
client in this context (i don't think we need to), then the Security
Considerations should mention for the server that it should *not* assume
that the message IDs are unpredictable, and so shouldn't do things like
forward the packets over a link that doesn't have the same protections.

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 28 Apr 2017 09:23:24 -0700

> checked, and only for the *current* definition of those protocols.

right, it only "works" in the sense that i've documented how existing
versions are demultiplexable.  In the text you quote above, i wasn't
saying it works for *all* client-speaks-first, stream-based protocols, i
was saying that it *can't* work for non-stream protcols, or for
protocols where the server speaks first.

> port's assignee, and they confirm that their service will never conflict

i think we're in violent agreement here :)

> on the entire port space.

I don't think i understand what you're saying here.  The document is
about how a server can distinguish between existing versions of DNS and
existing versions of HTTP.  it's not making any claims about any other
service.  are you suggesting that it is making such a claim?

          --dkg

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 10:06:11 -0700

> On Apr 28, 2017, at 9:23 AM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> 

I'm saying that the statement that it works now is just that.

It can't be a standard. It can't be a bcp. I don't see how it can be a WG doc outside of HTTPbis.

IMO it falls under the "hazard to the Internet" part where it might not even qualify as a valid individual submission.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 10:09:58 -0700

> On Apr 28, 2017, at 9:52 AM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> "suspicious"), not *subject*.  

Sorry - misread that.  Yes, new ports and new services are often treated as suspect. That's partly true (they could be) but partly bad (forcing us to use only what we already have).

> One of the aims of the draft is to make

But using any existing ports for new behaviors is simply not your right.
...
> talking with the HTTP folks soon.

Ok.  I really don't care if they allow this, but they need to allow this.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Apr 2017 19:41:41 +0100

Bit of a nit and possibly moot but...

> Ok.  I really don't care if they allow this, but they need to allow this.

I think that puts far too much emphasis on WGs "owning" things.
They don't. IMO IETF consensus wins (where it exists) over WGs
and IANA DEs and most or all other things in the IETF context.

That said, I do agree it'd be crazy to document this without
having gotten and taken into account feedback from folks expert
in http.

Cheers,
S.

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 12:44:19 -0700

> I think that puts far too much emphasis on WGs "owning" things.

The assignee of the port "owns" it, not the WG.

For IESG-owned ports, specified by standards-track RFCs, the ownership
is the IESG.

> and IANA DEs and most or all other things in the IETF context.
I don't understand "IETF consensus wins...over WGs". In this case, you'd
need to clearly state that this doc updates the HTTP spec, indicate that
it redefines the services on ports 80 and 443, and get IETF consensus to
move forward.

I agree - it's not genuflecting in front of the HTTP WG, but I wouldn't
be surprised if cross-area review solicited their opinion.

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".

Joe

---

From: Hugo Connery <[email-masked]>
Date: Fri, 28 Apr 2017 21:57:45 +0200

Joe,

[snip].

> But using any existing ports for new behaviors is simply not your

I could not more vehemently disagree.

1) DKG is publishing an idea to the community, not taking over
anything.

2) I will run whatever software on my end-point using any port 
that I wish.  End of story.  Standards exist to encourage compliance,
not demand it.  

/Hugo

[snip].

-- 

Hugo Connery, Head of IT, DTU Environment

"There is no cloud, only other people's computers".  FSF

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 28 Apr 2017 23:37:35 +0300

> it works as currently specd".

The properties this draft exploits for detection are completely
fundamential to HTTP/1.x and HTTP/2. There is no way anything that
breaks those properties can be deployed on mass scale without a new
ALPN, which should be ample warning to the server that new things
are going on.

This isn't "unextendable because of middleboxes", it is "unextendable
because the endpoints can't negotiate".

-Ilari

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 15:24:06 -0700

> ALPN, which should be ample warning to the server that new things

All I'm asking is that this doc makes it very clear that it intends to
redefine the services on ports 80 and/or 443, if that's the way you go.

I'll leave it to others to decide whether that's a good idea or not.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 15:29:43 -0700

Hugo,

> 1) DKG is publishing an idea to the community, not taking over
That idea encourages others to squat on an existing port. I doubt either
the IESG or IANA would allow that to proceed as an RFC of any kind.

> that I wish.  End of story. 
I agree fully with that story - any service can be run on any port.

However, the integrity of the very nature of assigned ports requires is
based on the expectation that endpoints run only the assigned service on
the corresponding assigned port *except when other direct information
indicates otherwise* (e.g., port override in a URL, mDNS entry, etc.)

>  Standards exist to encourage compliance,
> not demand it.  
That undermines the very nature of a standard.

If you want others to follow your laws, you have to respect theirs.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 Apr 2017 09:21:39 +1000

> the IESG or IANA would allow that to proceed as an RFC of any kind.

Actually it is proposing a extension to the existing port usage
that co-exists.  Whether it was said well or not is a different
matter.  Writing a draft is how we propose extensions.

Squatting would be just doing it then begging forgiveness afterwards.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 16:25:13 -0700

> On Apr 28, 2017, at 4:21 PM, Mark Andrews <[email-masked]> 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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 Apr 2017 09:31:37 +1000

In message <[email-masked]>, Joe Touch writes:
> 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.

It would need a Updates header for the HTTP RFCs.

IANA would need to add this document as a additional reference for
port 443.

This stuff however is dotting the i's and crossing the t's.

Mark

---

From: Hugo Connery <[email-masked]>
Date: Sat, 29 Apr 2017 02:44:45 +0200

On Fri, 2017-04-28 at 16:25 -0700, Joe Touch wrote:
> The IANA considerations at least need to make that clear.
[snip].

+1 "Writing a draft ...".  

The multi-decade effort to publish, update and revise the process 
for participation in IANA affairs has failed?  Its not "clear" yet?

# [Insert responses here.]

/Hugo Connery

---

From: Hugo Connery <[email-masked]>
Date: Sat, 29 Apr 2017 03:21:26 +0200

> because the endpoints can't negotiate".

If we accept DKG's proof, it works on what *is*. 

"Cant negotiate"?  There is no negotiation.  The "server" demuxes on 
published, known, accepted, delineated protocol standards.  

Cant fix future changes and cant fix non-end-points screwing with the
stream.

Am I missing something?

/Hugo