Subject: [dns-privacy] FW: New Version Notification for draft-mglt-dprive-dns-uri-00.txt

From: Daniel Migault <[email-masked]>
Date: Thu, 19 Mar 2020 03:10:16 +0000

Hi, 

Please find a draft describes URIs that describes the DNS resource being accessed through DNS53, DoT and DoH. 

Any comment / suggestions are welcome. 

Yours, 
Daniel

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: mercredi 18 mars 2020 22:57
To: Daniel Migault <[email-masked]>
Subject: New Version Notification for draft-mglt-dprive-dns-uri-00.txt

A new version of I-D, draft-mglt-dprive-dns-uri-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository.

Name:		draft-mglt-dprive-dns-uri
Revision:	00
Title:		Domain Name System Uniform Resource Identifiers for DNS over HTTPS and DNS over TLS
Document date:	2020-03-18
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-mglt-dprive-dns-uri-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mglt-dprive-dns-uri/
Htmlized:       https://tools.ietf.org/html/draft-mglt-dprive-dns-uri-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mglt-dprive-dns-uri

Abstract:
   Today DNS resources may also be accessed using multiple transport
   which includes DNS over UDP/TCP port 53 [RFC1034],[RFC1035].  DNS
   over TLS [RFC7858] or DNS over HTTPS [RFC8484].  This document
   describes URIs that describes the DNS resource as well as indicate
   the transport to access the resource.

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: Ted Hardie <[email-masked]>
Date: Thu, 19 Mar 2020 10:11:20 -0700

Hi Daniel,

I'm not sure I understand the need here.  The existing DNS URI scheme uses
the standard authority semantics, so it permits a port.   It seems like
using that gives you the same semantics as these additional schemes.  That
is:

dns://host.example:53/www.example.org.?clAsS=IN;tYpE=A

dns://host.example:853/www.example.org.?clAsS=IN;tYpE=A

dns://host.example:443/www.example.org.?clAsS=IN;tYpE=A

seem to handle the cases where you need to specifically call out DNS is
being served over traditional transports (UDP and TCP over 53), DoT, and
DoH.

What am I missing here?

thanks,

Ted

On Thu, Mar 19, 2020 at 9:52 AM Daniel Migault <daniel.migault=
[email-masked]> wrote:

> A new version of I-D, draft-mglt-dprive-dns-uri-00.txt has been
> successfully submitted by Daniel Migault and posted to the IETF repository.
>
> URL:
> https://www.ietf.org/internet-drafts/draft-mglt-dprive-dns-uri-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mglt-dprive-dns-uri/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mglt-dprive-dns-uri
>
>
> Abstract:
> 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
>
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 19 Mar 2020 14:15:50 -0400

Hi Ted,

Thanks for the feed back. The dns uri scheme has the port optional and
provides port flexibility. If we are using the port as an indication of the
transport protocol, we are losing this flexibility. A consequence is that
is it would prevent using other ports than non standard port. My impression
also is that some people are willing to deploy DoT or DoH on non standard
port, thought I might wrong.

For DoH, my understanding is that URI is formed according to the URI
template. I think that being able to provide the path could be useful
especially when different paths will be associated to different service.
Maybe additional element may also be useful to add.  I do not think the
current dns scheme enables this and I would be happy to have your thoughts
on it as I am not particularly familiar with uri template.

Basically using the old dns uri, this would be something like:

dns://host.example:443/dns-with-parental-protection/
www.example.org?clAsS=IN;tYpE=A

dns://host.example:443/dns-without-filtering/www.example.org?clAsS=IN;tYpE=A

Yours,

Daniel

-- 
Daniel Migault
Ericsson

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Mar 2020 11:49:30 -0700

Hi Daniel,

On Thu, Mar 19, 2020 at 11:16 AM Daniel Migault <[email-masked]> wrote:

> provides port flexibility.
>

I believe the port is optional to include in any URI, but I believe support
for a port is mandatory to implement.  Are you aware of implementations
that don't implement it?

If we are using the port as an indication of the transport protocol, we are
> losing this flexibility. A consequence is that is it would prevent using
> other ports than non standard port.
>

I think it means there's a different trade-off.  If you use an existing
port in a non-standard way, this will fail (and that's pretty correct
behavior in the face of squatting).  If you use a non-standard port, you
can use this mechanism to specify the port.  The client would then need to
attempt the connections with its preferred mechanism (for the TLS ones,
using ALPN) and then decide whether to fall back to less-preferred methods
if those are not available.  I would strongly urge that preference go from
most confidential transport to less confidential transports, but that would
ultimately be a client decision.

At least from my point of view, what you appear to want is configuration
protocol, but neither what you specified nor the original is a DNS client
configuration protocol.  They primarily provide a reference to specific
resource record data in the DNS, and this form:

dns:www.example.com?clAsS=IN;tYpE=A

looks like it ought to be the most common; it tells you the reference to a
specific RR, without requiring you to get it from anywhere in particular.
That works with whatever resolver you have configured, at least in the
common case.

The extended forms, which name or provide an address for a specific
resolver are useful (e.g. for split DNS), but I think creating a bunch of
different URI schemes to extend that to specify a protocol is more harmful
than helpful, as you then have an equivalence problem.  Are
dot://server.example:2836/:www.example.com?clAsS=IN;tYpE=A and dns:
www.example.com?clAsS=IN;tYpE=A presumed to be equivalent or not?

What that suggests is, if you really believe the trade-off to focus on
specific servers and non-standard ports is critical, that you should mint a
single URI scheme for the purpose, with a mandatory paramater that lists
the transports .  I would personally still feel that was heading this in
the wrong direction, but it would avoid some of the worst questions about
equivalence.

regards,

Ted

> My impression also is that some people are willing to deploy DoT or DoH on
> non standard port, thought I might wrong.
>
>
>
>> I'm not sure I understand the need here.  The existing DNS URI scheme
>> uses the standard authority semantics, so it permits a port.   It seems
>> like using that gives you the same semantics as these additional schemes.
>> That is:
>>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Mar 2020 19:35:20 +0000

On Mar 19, 2020, at 11:49 AM, Ted Hardie <[email-masked]> wrote:
> 
> What that suggests is, if you really believe the trade-off to focus on specific servers and non-standard ports is critical, that you should mint a single URI scheme for the purpose, with a mandatory paramater that lists the transports .  I would personally still feel that was heading this in the wrong direction, but it would avoid some of the worst questions about equivalence.
> 

+1. This proposal really seems like both overkill and underspecified. For the latter, note that DoH allows multiple formats for the queries and responses, but that is not (AND SHOULD NOT) be specified in the proposed "doh:".

Instead, it is fine to have a short document that says little more than "clients that know multiple ways of making DNS requests might try multiple transports when acting on a 'dns:' URI".

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Thu, 19 Mar 2020 16:14:34 -0400

On Thu, Mar 19, 2020 at 2:49 PM Ted Hardie <[email-masked]> wrote:

> I believe the port is optional to include in any URI, but I believe
> support for a port is mandatory to implement.  Are you aware of
> implementations that don't implement it?
>
> If we are using the port as an indication of the transport protocol, we
>> are losing this flexibility. A consequence is that is it would prevent
>> using other ports than non standard port.
>>
>
> behavior in the face of squatting).
>

I agree.

If you use a non-standard port, you can use this mechanism to specify the
> port.  The client would then need to attempt the connections with its
> preferred mechanism (for the TLS ones, using ALPN) and then decide whether
> to fall back to less-preferred methods if those are not available.  I would
> strongly urge that preference go from most confidential transport to less
> confidential transports, but that would ultimately be a client decision.
>

This is correct that try and error could be use, but I would have prefer to
avoid this. If the client is not able to specify explicitly the transport,
I have the impression the choice will be left to the resolver. Typically,
the resolver could downgrade to DNS53 without the client being able to
enforce DoT or DoH is needed. Typically, resolver.com may abort the TLS
session and downgrade to DNS53. On a performance point of view it may end
up in multiple TLS session (1 per server if alpn is supported, many more
otherwise). On a privacy point of view, it might force the client to leak
its preference, which might be an issue in some case. I would prefer if
possible the client not top go through this discover step.

> That works with whatever resolver you have configured, at least in the

 This is correct that the the dns scheme is focused on the DNS data with
little care on how the data is retrieved. The reason I though of using
different schemes was similar to have the https scheme versus the http
scheme. On one hand, I believe the current dns scheme is not sufficient, on
the other hand, I may go a bit to far and agree that we might be too close
to a configuration.

> www.example.com?clAsS=IN;tYpE=A presumed to be equivalent or not?
I agree there will be some overlap.

> the wrong direction,

When you propose a single uri scheme, would the single uri scheme be dns or
should we use a different one like dnss for example (following https) ?
Would that scheme reserved for dns on non standard port ? In both cases, I
still see some overlap with the dns scheme.

That said, I understand, the creation of another scheme to provides a hint
on the transport is not moving in the right direction. It is unclear to me
why this woudl not be recommended and, just for my personal comprehension,
how dns versus (dnss or dots) would differ from http versus https.

> but it would avoid some of the worst questions about equivalence.
>
> regards,
>
> Ted
>
>
>
>> My impression also is that some people are willing to deploy DoT or DoH
>> on non standard port, thought I might wrong.
>>
>>
>>
>>>> Please find a draft describes URIs that describes the DNS resource
>>>> being accessed through DNS53, DoT and DoH.
>>>>
>>>> https://tools.ietf.org/html/draft-mglt-dprive-dns-uri-00
>>>> Htmlized:

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Thu, 19 Mar 2020 16:37:44 -0400

Thanks Paul for the comment. I guess the reason for overkill is that too
many schemes are created. The reason for underspecified is that the
proposed doh scheme only reflects a subset of the parameters provided by a
uri template.  On the other hand I understand that parameters of the URI
template should not be provided as part of the URI scheme. Am I correct ?

On Thu, Mar 19, 2020 at 3:35 PM Paul Hoffman <[email-masked]> wrote:

> +1. This proposal really seems like both overkill and underspecified. For
> the latter, note that DoH allows multiple formats for the queries and
> responses, but that is not (AND SHOULD NOT) be specified in the proposed
> "doh:".
>
> Instead, it is fine to have a short document that says little more than
> "clients that know multiple ways of making DNS requests might try multiple
> transports when acting on a 'dns:' URI".
>
>
Is your suggestion to have a parameter that indicates the use of (tls?,
dot, doh) ?

> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> [email-masked]

-- 
Daniel Migault
Ericsson

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Mar 2020 20:50:49 +0000

On Mar 19, 2020, at 1:37 PM, Daniel Migault <[email-masked]> wrote:
> 
> Thanks Paul for the comment. I guess the reason for overkill is that too many schemes are created. The reason for underspecified is that the proposed doh scheme only reflects a subset of the parameters provided by a uri template.  On the other hand I understand that parameters of the URI template should not be provided as part of the URI scheme. Am I correct ? 
> 

Correct. People can't do parameters in URI schemes reliably at all.

As for your earlier question about http: and https:, many people now think in retrospect that that was a well-intentioned mistake. The fact that you have so many choices in your draft shows that it will only get worse.

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Thu, 19 Mar 2020 17:13:22 -0400

ok... so it makes probably more sense to document how the dns scheme
handles DoH and DoT rather than creating new schemes. Thanks for the
comments!

Yours,
Daniel

On Thu, Mar 19, 2020 at 4:50 PM Paul Hoffman <[email-masked]> wrote:

> As for your earlier question about http: and https:, many people now think
> in retrospect that that was a well-intentioned mistake. The fact that you
> have so many choices in your draft shows that it will only get worse.
>
> --Paul Hoffman

-- 
Daniel Migault
Ericsson