Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Tony Finch
Paul Vixie  wrote:
> Ted Lemon wrote:
> >
> > For your laptop use case, why wouldn't you just have the thing running
> > on the laptop do truncation if the answer is too long?
>
> that would be low fidelity.

I'm interested to know what breaks with something like dnscrypt-proxy or
stubby that works with your proxy.

>From a quick look, I think your proxy doesn't handle AXFR and (more
generally) doesn't map client TCP connections onto server TCP connections,
so it doesn't allow a client to distinguish between servers that have
serial vs concurrent DNS-over-TCP request handling in a way that a truly
high-fidelity tunnel would.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Cromarty, Forth: North 5 to 7, occasionally gale 8 in Forth, becoming variable
3 or 4. Moderate or rough. Sleet, fair later. Good occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ted Lemon
On Apr 4, 2018, at 2:57 PM, Paul Vixie  wrote:
> no. it uses a DNS response message of rcode SERVFAIL for error signalling. 
> so, it is as transparent as possible, and no more.

Okay.   So the upstream proxy is intended to simply take the "tcp" or "udp" 
indication and do the query using tcp or udp as indicated?   What if I write a 
proxy that doesn't support this behavior—will your downstream proxy fail to 
interoperate with it?   E.g., if it does the query using TCP, or automatically 
fails over to TCP if it gets a truncated response, and therefore returns a long 
response to a UDP query, will bad things happen?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Ted Lemon wrote:

On Apr 4, 2018, at 2:35 PM, Paul Vixie > wrote:

could this be done with a resolver using non-proxy DOH as a transport
to its forwarder? sure. but that puts semantic intelligence in the
middle, which will introduce configuration, logging, monitoring,
diagnosis, upgrade, and patching costs. i don't want those here.


So essentially this is {UDP | TCP}-over-HTTPS, with constraints on the
destination port?


no. it uses a DNS response message of rcode SERVFAIL for error 
signalling. so, it is as transparent as possible, and no more.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ted Lemon
On Apr 4, 2018, at 2:35 PM, Paul Vixie  wrote:
> could this be done with a resolver using non-proxy DOH as a transport to its 
> forwarder? sure. but that puts semantic intelligence in the middle, which 
> will introduce configuration, logging, monitoring, diagnosis, upgrade, and 
> patching costs. i don't want those here.

So essentially this is {UDP | TCP}-over-HTTPS, with constraints on the 
destination port?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Ted Lemon wrote:

On Apr 4, 2018, at 1:23 PM, Paul Vixie > wrote:

you've cut too much context. my answer was to "just truncate". your
followup is about "which middlebox."


Here's what I was replying to:


For your laptop use case, why wouldn't you just have the thing running
on the laptop do truncation if the answer is too long?


that would be low fidelity. i need to run clients whose internet
experience will not be influenced by middleboxes.


So you've said that the client's experience will be influenced by
middleboxes.


i intended this to be heard as "will otherwise be influenced by 
middleboxes".



I'm trying to understand what the scenario is where this
would happen. Hence my diagram:

LAPTOPDNS-over-https-proxy<---link b--->Full Service
Resolver<---internet--->Authoritative servers

That is, what is the problem you are trying to avoid that requires the
proxy to transparently tunnel rather than simply answering the query?


the proxy is transparent. from https://github.com/BII-Lab/DNSoverHTTP:


The proxy service does not interpret the DNS query or response in any
way. It could be DNS, EDNS, or something not yet invented at the time
of this writing. The only requirement is that each request message
solicits exactly one response message. If anything at all goes wrong
with the proxy service, the stub client will hear a DNS SERVFAIL
response.


i intend that the endpoints (who are real dns speakers and listeners) be 
able to evolve, or never evolve, according to their own drumbeats.


the real middlebox that's otherwise in the way is in my hotel room or 
coffee shop, and knows that udp/53 is a service address, and 
policy-routes my dns traffic to its own agent, which thinks it knows 
what DNS has to look like, and can't handle modern (1999-era) extensions 
like EDNS.


by putting these messages inside https (a virtual high fidelity middle 
box), i make them invisible to the hotel's physical low fidelity middle 
box. and by respecting the originator's transport choice, i remain 
transparent to its strategy to use edns-512, edns-1280, tcp, dns, and so 
on, in whatever order it wants to do.


could this be done with a resolver using non-proxy DOH as a transport to 
its forwarder? sure. but that puts semantic intelligence in the middle, 
which will introduce configuration, logging, monitoring, diagnosis, 
upgrade, and patching costs. i don't want those here.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ted Lemon
On Apr 4, 2018, at 1:23 PM, Paul Vixie  wrote:
> you've cut too much context. my answer was to "just truncate". your followup 
> is about "which middlebox."

Here's what I was replying to:

>> For your laptop use case, why wouldn't you just have the thing running
>> on the laptop do truncation if the answer is too long?
> 
> that would be low fidelity. i need to run clients whose internet experience 
> will not be influenced by middleboxes.

So you've said that the client's experience will be influenced by middleboxes.  
 I'm trying to understand what the scenario is where this would happen.   Hence 
my diagram:

LAPTOPDNS-over-https-proxy<---link b--->Full Service 
Resolver<---internet--->Authoritative servers

That is, what is the problem you are trying to avoid that requires the proxy to 
transparently tunnel rather than simply answering the query?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Ted Lemon wrote:

On Apr 4, 2018, at 12:42 PM, Paul Vixie > wrote:

that would be low fidelity. i need to run clients whose internet
experience will not be influenced by middleboxes.


I'm having trouble figuring out where a middlebox would be here that
would reduce fidelity. Isn't the point of what you're doing to
completely bypass any middleboxes that are in the way?

I think the diagram looks like this:

LAPTOPDNS-over-https-proxy<---link b--->Full Service
Resolver<---internet--->Authoritative servers

Where is the middlebox that's going to reduce fidelity?


you've cut too much context. my answer was to "just truncate". your 
followup is about "which middlebox."


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ted Lemon
On Apr 4, 2018, at 12:42 PM, Paul Vixie  wrote:
> that would be low fidelity. i need to run clients whose internet experience 
> will not be influenced by middleboxes.

I'm having trouble figuring out where a middlebox would be here that would 
reduce fidelity.   Isn't the point of what you're doing to completely bypass 
any middleboxes that are in the way?

I think the diagram looks like this:

LAPTOPDNS-over-https-proxy<---link b--->Full Service 
Resolver<---internet--->Authoritative servers

Where is the middlebox that's going to reduce fidelity?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Ben Schwartz wrote:

If the stub and forwarder are both on your laptop, why do you need to
truncate?  Local UDP should have extremely large MTU.


i know this was addressed to me, but i didn't mention truncation, so 
it's to me a nonsequitur.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ben Schwartz
If the stub and forwarder are both on your laptop, why do you need to
truncate?  Local UDP should have extremely large MTU.

On Wed, Apr 4, 2018 at 12:42 PM, Paul Vixie  wrote:

>
>
> Ted Lemon wrote:
>
>> On Apr 4, 2018, at 11:49 AM, Paul Vixie > > wrote:
>>
>>> this is a far thinner solution than a full-service resolver, which
>>> would require local configuration and monitoring and so on, as well as
>>> topology stability that can't be guaranteed.
>>>
>>
>> For your laptop use case, why wouldn't you just have the thing running
>> on the laptop do truncation if the answer is too long?
>>
>
> that would be low fidelity. i need to run clients whose internet
> experience will not be influenced by middleboxes.
>
> I admit that this is more code, but it's not a lot more code, and
>> what you're doing instead is pretty hacky.
>>
>
> feel free to try it out:
>
> https://github.com/BII-Lab/DNSoverHTTP
>
> or:
>
> https://github.com/BII-Lab/DNSoverHTTPinGO
>
> these are out of date with respect to the current draft, but each works. i
> would like to see a standard that they can conform to, so that i'm safe
> building a larger infrastructure.
>
> The fact that it's not required to implement doesn't mean that it
>> doesn't contribute to the camel problem.
>>
>
> are we at the point where any of us can call anything we see no use for
> part of the camel problem? i'm hoping not, and so i'm going to ignore your
> statement here.
>
> "if you want to do this, here's an interoperable method" is this group's
> meme. it's not "this is the best engineering solution we were able to
> create for the problem we are willing to admit you might have."
>
>
> --
> P Vixie
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Ted Lemon wrote:

On Apr 4, 2018, at 11:49 AM, Paul Vixie > wrote:

this is a far thinner solution than a full-service resolver, which
would require local configuration and monitoring and so on, as well as
topology stability that can't be guaranteed.


For your laptop use case, why wouldn't you just have the thing running
on the laptop do truncation if the answer is too long?


that would be low fidelity. i need to run clients whose internet 
experience will not be influenced by middleboxes.



I admit that this is more code, but it's not a lot more code, and
what you're doing instead is pretty hacky.


feel free to try it out:

https://github.com/BII-Lab/DNSoverHTTP

or:

https://github.com/BII-Lab/DNSoverHTTPinGO

these are out of date with respect to the current draft, but each works. 
i would like to see a standard that they can conform to, so that i'm 
safe building a larger infrastructure.



The fact that it's not required to implement doesn't mean that it
doesn't contribute to the camel problem.


are we at the point where any of us can call anything we see no use for 
part of the camel problem? i'm hoping not, and so i'm going to ignore 
your statement here.


"if you want to do this, here's an interoperable method" is this group's 
meme. it's not "this is the best engineering solution we were able to 
create for the problem we are willing to admit you might have."


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Dave Lawrence wrote:

Martin Thomson writes:

Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
concede that I'm probably missing something.


I think that's right.  -05 with the original_transport optional
parameter accommodates the aims of that other draft.


yes.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Martin Thomson wrote:

On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman  wrote:

Martin: Are you saying that you want DOH to remove the optional parameter from 
the application/dns-udpwireformat registration? If so, what do you propose for 
the DNSOP WG?


Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
concede that I'm probably missing something.


the use case is not well-expressed. as a co-author, i apologize.


By my current understanding, draft-ietf-dnsop-dns-wireformat-http is
indistinguishable from a specific implementation of
draft-ietf-doh-dns-over-https.  That is, if a DOH server wanted to
service all its queries by forwarding requests to a resolver [1], I
can't see how that would be disallowed by DOH, and that's exactly what
draft-ietf-dnsop-dns-wireformat-http appears to describe.


it's a high-fidelity virtual middlebox, to work around low-fidelity 
actual middleboxes. it is not a new dns transport protocol, which would 
require client and server changes. dns-over-https is a thin drop-in.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ted Lemon
On Apr 4, 2018, at 11:49 AM, Paul Vixie  wrote:
> this is a far thinner solution than a full-service resolver, which would 
> require local configuration and monitoring and so on, as well as topology 
> stability that can't be guaranteed.

For your laptop use case, why wouldn't you just have the thing running on the 
laptop do truncation if the answer is too long?   I admit that this is more 
code, but it's not a lot more code, and what you're doing instead is pretty 
hacky.

The fact that it's not required to implement doesn't mean that it doesn't 
contribute to the camel problem.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Ted Lemon wrote:

On Apr 4, 2018, at 11:37 AM, Paul Vixie > wrote:

there's code that implements this. there are people using it. there
will be more of both. a standard will mean greater interoperability.


Why was the code written? Why are they using this?


where the client can't be upgraded to DOH, and the network can't be 
upgraded to add VPN's, this allows a name server to be reachable with 
full fidelity (no middleboxes, so EDNS works) and better-than-cleartext 
privacy. i use it on my laptop when in a hotel room or coffee shop.



What is it about this
solution that makes it preferable, for their use case, to a smart proxy
that is itself a full-service resolver and thus shouldn't tunnel
information about the query transport?


this is a far thinner solution than a full-service resolver, which would 
require local configuration and monitoring and so on, as well as 
topology stability that can't be guaranteed.



Given Bert's talk on camels, I think these are questions that are worth
asking, and the answer shouldn't be "because."


this would never be part of the mandatory-to-implement "DNS core".

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ted Lemon
On Apr 4, 2018, at 11:37 AM, Paul Vixie  wrote:
> there's code that implements this. there are people using it. there will be 
> more of both. a standard will mean greater interoperability.

Why was the code written?   Why are they using this?   What is it about this 
solution that makes it preferable, for their use case, to a smart proxy that is 
itself a full-service resolver and thus shouldn't tunnel information about the 
query transport?

Given Bert's talk on camels, I think these are questions that are worth asking, 
and the answer shouldn't be "because."

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Ted Lemon wrote:

On Apr 4, 2018, at 10:54 AM, Paul Vixie > wrote:

this is not a service. DOH is a service. this is a proxy, which i
would like to have be interoperable. please don't ask me to change
what i want to build; that would be out-of-scope.


Maybe another question to ask is "okay, Paul wants to build this, but
why does the IETF need to standardize it?"


same as for ECS: not universally popular, but better if interoperable.


I don't mean that the answer should be "it doesn't," but rather that I
don't actually see why this is valuable, and maybe I'm not the only one
who needs to hear more of a sales pitch.


there's code that implements this. there are people using it. there will 
be more of both. a standard will mean greater interoperability.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ted Lemon
On Apr 4, 2018, at 10:54 AM, Paul Vixie  wrote:
> this is not a service. DOH is a service. this is a proxy, which i would like 
> to have be interoperable. please don't ask me to change what i want to build; 
> that would be out-of-scope.

Maybe another question to ask is "okay, Paul wants to build this, but why does 
the IETF need to standardize it?"

I don't mean that the answer should be "it doesn't," but rather that I don't 
actually see why this is valuable, and maybe I'm not the only one who needs to 
hear more of a sales pitch.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie
ray, i won't engage on the question, should i want to do this. the 
working group mantra is interoperability -- as in, if you want to do 
this, here's an interoperable way. i'm not asking that the working group 
ratify the intent, or recommend the method. (as went ECS.)


the proxy is transparent. we list it in resolv.conf or as a forwarder. 
it regenerates the queries on the far side. it has to differentiate 
between tcp and udp because the unmodified client is making strategy 
decisions and implementing those using that transport choice.


this is not a service. DOH is a service. this is a proxy, which i would 
like to have be interoperable. please don't ask me to change what i want 
to build; that would be out-of-scope.


paul

re:

Ray Bellis wrote:

On 04/04/2018 13:20, Paul Vixie wrote:


tcp and udp are the two ways a query might have reached the
initiating proxy, and that distinction is the only thing the
responding proxy needs to know.


I disagree, I don't think that transport protocols should continue to be
used as things that should be used for policy decisions.

Per my previous message, they were a suitable proxy (no pun intended)
for "this came from an unspoofable address", or "this channel can handle
large responses" but there are other ways to achieve that now that
aren't strictly transport.

For example, presence of EDNS cookies satisfies the "unspoofable
address" and therefore would permit RRL to be skipped for that client,
but "UDP with Cookies" isn't a transport.

[I appreciate that this isn't the best example because that cookie
*might* get all the way through to the backend server anyway.  But it
also might not].


if DOH becomes a standard transport, then we could add that
identifier as well -- but i don't think a client capable of DOH is
going to be using this particular proxy method.


We already have DNS-over-TLS, DNS-over-DTLS, and folks are working on
DNS-over-QUIC too.  None of those are true "transports", but server
operators may wish to make policy decisions based on the resulting
meta-properties of them.

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ray Bellis
On 04/04/2018 13:20, Paul Vixie wrote:

> tcp and udp are the two ways a query might have reached the
> initiating proxy, and that distinction is the only thing the
> responding proxy needs to know.

I disagree, I don't think that transport protocols should continue to be
used as things that should be used for policy decisions.

Per my previous message, they were a suitable proxy (no pun intended)
for "this came from an unspoofable address", or "this channel can handle
large responses" but there are other ways to achieve that now that
aren't strictly transport.

For example, presence of EDNS cookies satisfies the "unspoofable
address" and therefore would permit RRL to be skipped for that client,
but "UDP with Cookies" isn't a transport.

[I appreciate that this isn't the best example because that cookie
*might* get all the way through to the backend server anyway.  But it
also might not].

> if DOH becomes a standard transport, then we could add that 
> identifier as well -- but i don't think a client capable of DOH is
> going to be using this particular proxy method.

We already have DNS-over-TLS, DNS-over-DTLS, and folks are working on
DNS-over-QUIC too.  None of those are true "transports", but server
operators may wish to make policy decisions based on the resulting
meta-properties of them.

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Paul Vixie



Ray Bellis wrote:

On 04/04/2018 04:39, Dave Lawrence wrote:


I think that's right.  -05 with the original_transport optional
parameter accommodates the aims of that other draft.


but ignores the concerns I raised yesterday that simply indicating "tcp"
or "udp" is insufficient to allow a server to make policy decisions
based on the meta-properties of the original request and its transport
(whether that be a "real" tranport protocol like UDP or TCP or a
pseudo-transport like DNS-o-TLS, or DNS-o-QUIC, etc).


tcp and udp are the two ways a query might have reached the initiating 
proxy, and that distinction is the only thing the responding proxy needs 
to know. if DOH becomes a standard transport, then we could add that 
identifier as well -- but i don't think a client capable of DOH is going 
to be using this particular proxy method.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ray Bellis
[added DOH WG to the cc:]

On 04/04/2018 04:39, Dave Lawrence wrote
> I think that's right.  -05 with the original_transport optional
> parameter accommodates the aims of that other draft.

but ignores the concerns I raised yesterday that simply indicating "tcp"
or "udp" is insufficient to allow a server to make policy decisions
based on the meta-properties of the original request and its transport
(whether that be a "real" tranport protocol like UDP or TCP or a
pseudo-transport like DNS-o-TLS, or DNS-o-QUIC, etc).

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-04 Thread Ray Bellis
On 04/04/2018 04:39, Dave Lawrence wrote:

> I think that's right.  -05 with the original_transport optional
> parameter accommodates the aims of that other draft.

but ignores the concerns I raised yesterday that simply indicating "tcp"
or "udp" is insufficient to allow a server to make policy decisions
based on the meta-properties of the original request and its transport
(whether that be a "real" tranport protocol like UDP or TCP or a
pseudo-transport like DNS-o-TLS, or DNS-o-QUIC, etc).

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-03 Thread Dave Lawrence
Martin Thomson writes:
> Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
> concede that I'm probably missing something.

I think that's right.  -05 with the original_transport optional
parameter accommodates the aims of that other draft.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-03 Thread Martin Thomson
On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman  wrote:
> Martin: Are you saying that you want DOH to remove the optional parameter 
> from the application/dns-udpwireformat registration? If so, what do you 
> propose for the DNSOP WG?

Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
concede that I'm probably missing something.

By my current understanding, draft-ietf-dnsop-dns-wireformat-http is
indistinguishable from a specific implementation of
draft-ietf-doh-dns-over-https.  That is, if a DOH server wanted to
service all its queries by forwarding requests to a resolver [1], I
can't see how that would be disallowed by DOH, and that's exactly what
draft-ietf-dnsop-dns-wireformat-http appears to describe.

Convince me that this isn't the case (or not, and I'll be in the rough on this).

--Martin

[1] ...after randomizing the ID.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-04-03 Thread Paul Hoffman
On Apr 3, 2018, at 2:58 AM, Martin Thomson  wrote:
> 
> If I understand your response (not sure that I do), that seems pretty
> academic and not at all persuasive.  

to you. It was persuasive enough for the DNSOP WG to adopt the document as 
a WG item.

> For instance, if a client cared
> about testing TCP capabilities, it can always do its own resolution.

That's not what draft-ietf-dnsop-dns-wireformat-http is about.

Martin: Are you saying that you want DOH to remove the optional parameter from 
the application/dns-udpwireformat registration? If so, what do you propose for 
the DNSOP WG?

--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

2018-03-26 Thread Paul Hoffman
On Mar 26, 2018, at 7:08 AM, Paul Vixie  wrote:
> Paul Hoffman wrote:
>> Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining
>> a new media type seems like overkill, particularly given that it will
>> be transporting *the exact same* data as an existing media type.
>> Instead, an optional parameter could be added to the
>> application/dns-udpwireformat registration in the DOH document.
>> 
>> Proposal:
>> 
>> =
>> 
>> In the media type definition, change "Optional parameters" to:
>> 
>> Optional parameters: original_transport original_transport has two
>> defined values, "udp" and "tcp". This is only expected to be used by
>> servers.
> 
> s/servers/proxies/

Maybe? I can't tell from the current draft if a proxy client would need to send 
a transport type.


>> Also in the the DOH document, under Operational Considerations, we
>> would add:
>> 
>> This protocol does not define any use for the original_transport
>> optional parameter of the application/dns-udpwireformat media type.
>> 
>> =
>> 
>> Then draft-ietf-dnsop-dns-wireformat-http could define the use of
>> that optional parameter as it sees fit.
> 
> so this would look like
> 
> content-type: application/dns-udpwireformat; tcp

Not quite.
   content-type: application/dns-udpwireformat; original_transport=tcp

--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop