Re: [Add] [EXTERNAL] I-D Action: draft-ietf-add-ddr-01.txt

[Tommy Jensen <[e-mail]>]

Hey Chris: apparently only ones we have already closed on checking. You can ignore what I said.

Hey Ben,

I appreciate your efforts in keeping up with the base draft, but I think your proposal is best served by a separate document. The expanded scope it introduces significantly lowers the security posture of DDR overall, which you indirectly acknowledge in the text:

“If the client does not have a Validation Identity, or the Validation Identity
was discovered insecurely (e.g. via CNAME), the client SHOULD limit the
validity duration of the discovered information (e.g. the SVCB response
TTL) to no more than 5 minutes. The client MAY make use of this encrypted
connection, but SHOULD NOT assume that the connection is more secure
than an unencrypted connection.”

I do not think we should be trying to add this to a standard that otherwise provides connections of improved security. While DDR can be blocked by an on-path attacker, a successful upgrade can be trusted to be an entity designated by the original resolver owner. This PR introduces a mechanism where that is not true.

Since clients will have different opinions on the need to support DDR as it is currently defines versus this PR, we should provide them as separate documents to avoid clients deploying only partial standard support (as it seems likely many will choose to not support this option).

Thanks,
Tommy

From: Ben Schwartz <bemasc=[e-mail]>
Sent: Wednesday, June 16, 2021 8:11 AM
To: Chris Box <[e-mail]>
Cc: Tommy Jensen <[e-mail]>; [e-mail]
Subject: Re: [Add] [EXTERNAL] I-D Action: draft-ietf-add-ddr-01.txt

Thanks for the update.  On the "85%" topic, I've rebased my PR  to the latest draft: https://github.com/ietf-wg-add/draft-ietf-add-ddr/pull/11.

On Tue, Jun 15, 2021 at 1:25 PM Chris Box <[e-mail]<mailto:[e-mail]>> wrote:
Tommy,

It's a good set of improvements over the wording in -00. Thumbs up on those.

I certainly appreciate DDR (even with DNR added) doesn't entirely solve the 85% problem; Barbara and I have written up some thoughts on that which she'll be sharing to the list imminently.

Which Github bugs/issues were you referring to?

Chris

On Tue, 15 Jun 2021 at 00:05, Tommy Jensen <Jensen.Thomas=[e-mail]<mailto:[e-mail]>> wrote:
Hey everyone,

We have posted an update to DDR and welcome additional review. Many thanks to everyone who has reviewed so far. We are hoping to get additional feedback as we rev a -02 ahead of the deadline for IETF 111.

This version addresses some feedback regarding the use of IPv4/IPv6 examples, the use of IP hints, and some clarity of language regarding terminology ("equivalence" versus "designation") and scope.

I would like to highlight for the benefit of some feedback regarding scope that the scope of this draft remains limited in nature. For example, DDR has not and still does not attempt to solve the "85%" problem. You will see commentary on the GitHub bugs following that scoping.

Thanks,
Tommy

> -----Original Message-----
> From: Add <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
> Sent: Monday, June 14, 2021 3:59 PM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [EXTERNAL] [Add] I-D Action: draft-ietf-add-ddr-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Adaptive DNS Discovery WG of the IETF.
>
>         Title           : Discovery of Designated Resolvers
>         Authors         : Tommy Pauly
>                           Eric Kinnear
>                           Christopher A. Wood
>                           Patrick McManus
>                           Tommy Jensen
>       Filename        : draft-ietf-add-ddr-01.txt
>       Pages           : 12
>       Date            : 2021-06-14
>
> Abstract:
>    This document defines Discovery of Designated Resolvers (DDR), a
>    mechanism for DNS clients to use DNS records to discover a resolver's
>    encrypted DNS configuration.  This mechanism can be used to move from
>    unencrypted DNS to encrypted DNS when only the IP address of an
>    encrypted resolver is known.  It can also be used to discover support
>    for encrypted DNS protocols when the name of an encrypted resolver is
>    known.  This mechanism is designed to be limited to cases where
>    unencrypted resolvers and their designated resolvers are operated by
>    the same entity or cooperating entities.
>
>
> The IETF datatracker status page for this draft is:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> cker.ietf.org<http://cker.ietf.org>%2Fdoc%2Fdraft-ietf-add-
> ddr%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com<http://40microsoft.com>%7C4efbe3
> 5963a949fea69f08d92f8810a7%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C0%7C637593083738862826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sdata=aSaQVCpy5v%2B%2BrQY%2FO%2B58%2FpsuYInrrSFnFOSnIQQPeRw
> %3D&amp;reserved=0
>
> There is also an HTML version available at:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org<http://tf.org>%2Farchive%2Fid%2Fdraft-ietf-add-ddr-
> 01.html&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com<http://40microsoft.com>%7C4efbe3
> 5963a949fea69f08d92f8810a7%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C0%7C637593083738862826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sdata=zv0FOkEWCo9PbEcvzc%2FcjuZTWAi53Td6dsOuY5hKyEs%3D&amp;re
> served=0
>
> A diff from the previous version is available at:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org<http://tf.org>%2Frfcdiff%3Furl2%3Ddraft-ietf-add-ddr-
> 01&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com<http://40microsoft.com>%7C4efbe35963
> a949fea69f08d92f8810a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C637593083738862826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s
> data=QgeVUjM%2F5bSTseBkg0tytJ3RT0ztD56xoYmK4pKfJ%2Fs%3D&amp;reser
> ved=0
>
>
> Internet-Drafts are also available by anonymous FTP at:
> https://nam06.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.or
> g%2Finternet-
> drafts%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com<http://40microsoft.com>%7C4efb
> e35963a949fea69f08d92f8810a7%7C72f988bf86f141af91ab2d7cd011db47%7
> C1%7C0%7C637593083738862826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> &amp;sdata=%2Fc8xtaTsW%2BmcWpqCR6oHJkY6hyN%2B3K02Ae6%2BRpCfLN
> w%3D&amp;reserved=0
>
>
> --
> Add mailing list
> [e-mail]<mailto:[e-mail]>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org<http://tf.org>%2Fmailman%2Flistinfo%2Fadd&amp;data=04%7C01%7CJensen.Thomas
> %40microsoft.com<http://40microsoft.com>%7C4efbe35963a949fea69f08d92f8810a7%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637593083738862826%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C1000&amp;sdata=Z71SomUyHBgCR8RoMIfGzH7bcURYM
> 7CNUr2JfSvG%2BM0%3D&amp;reserved=0

--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add