Subject: [Add] R1.3 (was RE: WGLC for draft-ietf-add-dnr)

From: <[email-masked]>
Date: Thu, 10 Mar 2022 06:55:09 +0000

Re-,

Please see inline.

Cheers,
Med

De : Add <[email-masked]> De la part de Chris Box
Envoyé : mercredi 9 mars 2022 18:36
À : Deen, Glenn <Glenn_Deen=[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] WGLC for draft-ietf-add-dnr

Hi everyone.

    +-------------+---------------------------------------------------+

    | R1.3        | Discovery SHOULD support all encrypted DNS        |

    |             | protocols standardised by the IETF.               |

The requirement is approximately met, by virtue of building on SVCB. However I think the draft should normatively depend on draft-ietf-add-svcb-dns rather than the generic draft-ietf-dnsop-svcb-https.

[Med] Both are cited, but draft-ietf-dnsop-svcb-https is cited as normative because it is the authoritative reference for SvcParamKeys. Please note that draft-ietf-add-svcb-dns says also: “Future SvcParamKeys may also be applicable.”. The rationale is discussed in this text:

   Encrypted DNS options are designed to return a set of service
   parameters.  These parameters are encoded following the same rules
   for encoding SvcParams in Section 2.1 of [I-D.ietf-dnsop-svcb-https<https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr#ref-I-D.ietf-dnsop-svcb-https>].
   This encoding approach may increase the size of the options but it
   has the merit to rely upon an existing IANA registry and, thus, to
   accommodate new encrypted DNS protocols and service parameters that
   may be defined in the future.  For example, "dohpath" service
   parameter (Section 5.1 of [I-D.ietf-add-svcb-dns<https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr#ref-I-D.ietf-add-svcb-dns>]) supplies a
   relative DoH URI Template.

There's a point to clarify. It is not stated whether it is useful or valid for the SVCB Service Priority to be zero (i.e. AliasMode). I suspect not since it would mean the mandatory SvcParams could not be populated, and may require the client to perform an additional bootstrapping query, potentially over Do53.

[Med] Yes. Updated the text to make this explicit. Thanks.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Chris Box <[email-masked]>
Date: Wed, 23 Mar 2022 10:23:55 +0100

> *[Med] Both are cited, but draft-ietf-dnsop-svcb-https is cited as normative because it is the authoritative reference for SvcParamKeys. Please note that draft-ietf-add-svcb-dns says also: “*Future SvcParamKeys may also be applicable.*”. The rationale is discussed in this text:*
>
>
>
This feels odd to me, because only ietf-add-svcb-dns defines the "dns"
service type. It describes how encrypted DNS can be described in SvcParams.
In order to implement and gain the value of DNR, it is *always* necessary
to read ietf-add-svcb-dns. Simply reading draft-ietf-dnsop-svcb-https only
tells you there are some keys and associated values, for any generic
service.

Yes we need to support extensibility, but normatively depending on
ietf-add-svcb-dns should not prevent a future extension, e.g. one that
wants to define DNS over Avian Carrier with some new SvcParamKeys "coop"
and "feed".

There's a point to clarify. It is not stated whether it is useful or
valid for the SVCB Service Priority to be zero (i.e. AliasMode). I
suspect not since it would mean the mandatory SvcParams could not be
populated, and may require the client to perform an additional
bootstrapping query, potentially over Do53.
>
>
>
> *[Med] Yes. Updated the text to make this explicit. Thanks.*
>
>
On AliasMode, I agree with Ben's point that it's sometimes useful for a
router owner to outsource DNS to a third party. But I'm also concerned that
it weakens the security of DNR, namely losing its spoofing protections. I'd
be ok with a halfway house of permitting it, but noting the consequences.

Chris

---

From: <[email-masked]>
Date: Wed, 23 Mar 2022 15:33:24 +0000

Chris,

Relying on draft-ietf-dnsop-svcb-https is what ensures interoperability and extensibility. However, and after thinking about this further, I interpret your comment as if we need to indicate a minimum set of applicable parameters with some normative language:

We may consider the following:

===
OLD:
   Because distinct encrypted DNS protocols may be provisioned by a
   network (e.g., DoT, DoH, and DoQ) and that some of these protocols
   may make use of customized port numbers instead of default ones, the
   Encrypted DNS options are designed to return a set of service
   parameters.  These parameters are encoded following the same rules
   for encoding SvcParams in Section 2.1 of [I-D.ietf-dnsop-svcb-https].
   This encoding approach may increase the size of the options but it
   has the merit to rely upon an existing IANA registry and, thus, to
   accommodate new encrypted DNS protocols and service parameters that
   may be defined in the future.  For example, "dohpath" service
   parameter (Section 5.1 of [I-D.ietf-add-svcb-dns]) supplies a
   relative DoH URI Template.

NEW:
   Because distinct encrypted DNS protocols may be provisioned by a
   network (e.g., DoT, DoH, and DoQ) and that some of these protocols
   may make use of customized port numbers instead of default ones, the
   Encrypted DNS options are designed to return a set of service
   parameters.  These parameters are encoded following the same rules
   for encoding SvcParams in Section 2.1 of [I-D.ietf-dnsop-svcb-https].
   This encoding approach may increase the size of the options but it
   has the merit to rely upon an existing IANA registry and, thus, to
   accommodate new encrypted DNS protocols and service parameters that
   may be defined in the future.  At least the following service
   parameters SHOULD be supported by an implementation:

   alpn:  Used to indicate the set of supported protocols (Section 7.1
      of [I-D.ietf-dnsop-svcb-https]).

   port:  Used to indicate the target port number for the encrypted DNS
      connection (Section 7.2 of [I-D.ietf-dnsop-svcb-https]).

   ech:  Used to enable Encrypted ClientHello (ECH) (Section 7.3 of
      [I-D.ietf-dnsop-svcb-https]).

   dohpath:  Used to supply a relative DoH URI Template (Section 5.1 of
      [I-D.ietf-add-svcb-dns]).

==

If this change (or similar one) is agreed by the WG, then we have the text to justify listing I-D.ietf-add-svcb-dns as normative.

Cheers,
Med

De : Chris Box <[email-masked]>
Envoyé : mercredi 23 mars 2022 10:24
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] R1.3 (was RE: WGLC for draft-ietf-add-dnr)

This feels odd to me, because only ietf-add-svcb-dns defines the "dns" service type. It describes how encrypted DNS can be described in SvcParams. In order to implement and gain the value of DNR, it is always necessary to read ietf-add-svcb-dns. Simply reading draft-ietf-dnsop-svcb-https only tells you there are some keys and associated values, for any generic service.

Yes we need to support extensibility, but normatively depending on ietf-add-svcb-dns should not prevent a future extension, e.g. one that wants to define DNS over Avian Carrier with some new SvcParamKeys "coop" and "feed".

On AliasMode, I agree with Ben's point that it's sometimes useful for a router owner to outsource DNS to a third party. But I'm also concerned that it weakens the security of DNR, namely losing its spoofing protections. I'd be ok with a halfway house of permitting it, but noting the consequences.

Chris

---

From: Chris Box <[email-masked]>
Date: Wed, 23 Mar 2022 17:06:49 +0100

Med,

On Wed, 23 Mar 2022 at 16:33, <[email-masked]> wrote:

> I interpret your comment as if we need to indicate a minimum set of
> applicable parameters with some normative language:
>
> ...
>

Thanks, that gives us another approach to consider. Hopefully we'll get a
couple of minutes tomorrow for the WG to share their opinions on this.

Chris