Subject: [Doh] re original_transport indicator

From: Patrick McManus <[email-masked]>
Date: Thu, 5 Apr 2018 16:53:51 -0400

Hi All,

We've had quite a thread re the -05 optional parameter to the
dns-udpwireformat registration.

The parameter is defined as having no meaning for DoH, but was included to
accommodate a use case the dnsop wg is considering. Future proofing, if you
like.

Upon consideration (and a read of 6838), I think including this in doh is
premature because Media Type registrations can be updated by mechanisms
laid out in RFC6838 and in this case such an update could occur without
impacting existing DoH deployments. (i.e. it does not need to be future
proofed).

Therefore the definition of the parameter should accompany the work that
makes use of it if a future standards document chooses to go down that
path. As a bonus we avoid unused clutter if it doesn't happen. I also get
the feeling that there isn't yet strong consensus on the anticipated use
case or the exact form it needs to take - we should let that process work
itself out separately before registration.

I've chatted with Paul, and our recommendation is to remove the
original_transport parameter from DoH and encourage dnsop to update the
registration if/when a different standard needs to make use of it.

thoughts?

-Patrick

---

From: "Hewitt, Rory" <[email-masked]>
Date: Thu, 5 Apr 2018 20:56:40 +0000

Good idea - future-proofing is great in theory, but it sounds like there's a 
lot of non-consensus on the DNSOP side that we might end up adding something 
that is superseded anyway.

Rory

From: Patrick McManus [mailto:[email-masked]]
Sent: Thursday, April 5, 2018 1:54 PM
To: Martin Thomson <[email-masked]>
Cc: Ted Lemon <[email-masked]>; dnsop <[email-masked]>; DoH WG 
<[email-masked]>; Paul Vixie <[email-masked]>; Ray Bellis <[email-masked]>
Subject: [Doh] re original_transport indicator

Hi All,

Upon consideration (and a read of 6838), I think including this in doh is 
premature because Media Type registrations can be updated by mechanisms laid 
out in RFC6838 and in this case such an update could occur without impacting 
existing DoH deployments. (i.e. it does not need to be future proofed).

Therefore the definition of the parameter should accompany the work that makes 
use of it if a future standards document chooses to go down that path. As a 
bonus we avoid unused clutter if it doesn't happen. I also get the feeling 
that there isn't yet strong consensus on the anticipated use case or the exact 
form it needs to take - we should let that process work itself out separately 
before registration.

thoughts?

-Patrick

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Apr 2018 11:12:07 +1000

+1 to this.

And maybe there is an outcome that doesn't need this parameter.  I
probably misunderstood some of the expectations people have for the
parameter.  With the benefit of time and sleep, it's possible that I
now understand the disconnect.

My model of content-type - and by extension its parameters - is of a
description of the content.  However, it appears as though at least
some people had different uses for the parameter: for requests, it
would be an instruction/suggestion to the server to make a DNS request
using the identified transport; for responses, it would be a
description of where the DNS request came from.

I never considered that interpretation, but - assuming that this is
what it was - and the intent was to provide a means for the client to
control how the server makes requests (and to see how they were made).
In that case, I have a possible alternative design for the use case in
the dnsop draft.

Right now, DOH doesn't really say how a DNS API Server gets its
responses.  It could be that the API server is part of a resolver, or
it could be that the DNS API Server makes a request to another
resolver.  But specific uses of the DOH protocol could come with
additional constraints that would enable the use cases in the dnsop
draft, at least as I understand them.

If the goal of the dnsop draft is to extend the reach of a DNS client
(note: not a DNS API client) across a network that is in some way less
hostile to HTTP than it is to DNS, then I think that it can still use
DOH.  A DNS API server could be configured to operate in a very simple
mode with no caching, just direct transposition of a request from HTTP
to a request on UDP or TCP.  A DNS client could be configured with two
DNS API clients.  Each client uses a different DNS API Server
endpoint.  Those endpoints would be specifically configured to use
only UDP or TCP.

For instance:
https://use.only/tcp{?dns} would cause the server to make a request using TCP.
https://use.only/udp{?dns} would cause the server to make a request using UDP.

At this point, this is simple DOH, but with extra contextual
information about server operation.

The concerns about the requirement for HTTPS is a relevant concern.
If there are cases where an unprotected HTTP connection carrying DNS
is expected to traverse a network without modification where DNS
encounters difficulty, maybe the dnsop draft can concentrate on that
particular aspect of this.  I don't think that the suggestion in DOH
to use HTTP/2 is a problem; DOH permits the use of any version of
HTTP.

On Fri, Apr 6, 2018 at 6:53 AM, Patrick McManus <[email-masked]> wrote:
> makes use of it if a future standards document chooses to go down that path.
> As a bonus we avoid unused clutter if it doesn't happen. I also get the
> feeling that there isn't yet strong consensus on the anticipated use case or
> the exact form it needs to take - we should let that process work itself out
> separately before registration.
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Apr 2018 19:29:36 -0400

> description of where the DNS request came from.

my original design added an http header, which was seen as even worse. 
someone suggested adding to the content-type, and i went along with it 
even though there is no difference in actual type of actual content.

> draft, at least as I understand them.

this all sounds good to me.

> information about server operation.

i am generally supportive of this approach; in fact i wish i'd thought 
of it. the specifics will be different, as in:

/proxy_dns?proto=tcp
/proxy_dns?proto=udp

but i agree that encoding the original transport in the URI is better 
than either extending the content-type or adding another http header.

---

i object, as before, to "dns-udpwireformat" as a name. these are dns 
messages, which when carried by udp are raw, and when carried in tcp are 
preceded by a two-octet length indicator for framing of multiple 
messages sharing the same stream. so, the string to be registered should 
be "dns-message".

-- 
P Vixie

---

From: Martin Thomson <[email-masked]>
Date: Sat, 7 Apr 2018 14:30:05 +1000

On Sat, Apr 7, 2018 at 9:29 AM, Paul Vixie <[email-masked]> wrote:
> someone suggested adding to the content-type, and i went along with it even
> though there is no difference in actual type of actual content.

A header field isn't all bad.  At least from my perspective, anyway.
That said, it is true that adding to the content is a better choice.
I appreciate that this isn't a great fit in this case.

> i am generally supportive of this approach; in fact i wish i'd thought of
> it. the specifics will be different, as in:
>
> /proxy_dns?proto=tcp
> /proxy_dns?proto=udp

.../request{?dns}{?proto} is the way you would write that.

> preceded by a two-octet length indicator for framing of multiple messages
> sharing the same stream. so, the string to be registered should be
> "dns-message".

I agree with this principle, and have expressed similar concerns with
the name.  However, I just checked the media type registry [1] and I
think that a better choice is message/dns.  Just like message/http and
message/sip.

[1] https://www.iana.org/assignments/media-types/media-types.xhtml#message

---

From: Dave Lawrence <[email-masked]>
Date: Sat, 7 Apr 2018 01:10:14 -0400

Martin Thomson writes:
> I think that a better choice is message/dns.

I personally prefer this to dns-udpwireformat / dns-wireformat

---

From: Tony Finch <[email-masked]>
Date: Sat, 7 Apr 2018 20:31:33 +0100

> On 7 Apr 2018, at 00:29, Paul Vixie <[email-masked]> wrote:
> 
> i object, as before, to "dns-udpwireformat" as a name. these are dns messages, which when carried by udp are raw, and when carried in tcp are preceded by a two-octet length indicator for framing of multiple messages sharing the same stream. so, the string to be registered should be "dns-message".

Yes! Much nicer and more accurate.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Davey Song <[email-masked]>
Date: Sun, 8 Apr 2018 11:15:40 +0800

On 7 April 2018 at 07:29, Paul Vixie <[email-masked]> wrote:
> but i agree that encoding the original transport in the URI is better than
> either extending the content-type or adding another http header.
>

It sounds a better approch.  We can define the variables
"proto" in dnsop-dns-wireformat-http instead of adding a parameter of
content-type.

There is a sentence in DOH draft support new variables in URI.

   Future specifications for new media types MUST define the variables
   used for URI Template processing with this protocol.

I think it should edited a little bit : s/ new media/ new media types and
new use cases

> sharing the same stream. so, the string to be registered should be
+1

Davey

>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Paul Vixie <[email-masked]>
Date: Sun, 08 Apr 2018 14:11:53 -0400

sean gallagher did an excellent writeup on all this in arstechnica today:

https://arstechnica.com/information-technology/2018/04/how-to-keep-your-isps-nose-out-of-your-browser-history-with-encrypted-dns/

he didn't mention the bii/tisf proxy method from three years ago, but 
since our draft has languished somewhat, i can hardly blame him.

vixie