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

[Daniel Migault <[e-mail]>]

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

> Hi Daniel,
>
> On Thu, Mar 19, 2020 at 11:16 AM Daniel Migault <[e-mail]>
> wrote:
>
>> Hi Ted,
>>
>>
>>
>> Thanks for the feed back. The dns uri scheme has the port optional and
>> 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).
>

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.



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

 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.

>
> 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?
>
>
I agree there will be some overlap.

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

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.
>>
>>
>>
>> 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
>>
>> On Thu, Mar 19, 2020 at 1:44 PM Ted Hardie <[e-mail]> wrote:
>>
>>> 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=
>>> [e-mail]> wrote:
>>>
>>>> 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: [e-mail] <[e-mail]>
>>>> Sent: mercredi 18 mars 2020 22:57
>>>> To: Daniel Migault <[e-mail]>
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> dns-privacy mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>>
>>> _______________________________________________
>>> dns-privacy mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>

-- 
Daniel Migault
Ericsson