Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Daniel Migault <[e-mail]>]

Hi,

Thanks for your questions, please see inline some clarifications.

Yours,
Daniel

On Fri, Dec 25, 2020 at 3:27 PM Paul Hoffman <[e-mail]> wrote:

> On Dec 24, 2020, at 10:28 AM, Daniel Migault <[e-mail]> wrote:
> >
> > Hi,
> >
> > As the DNS is a global shared resource and its reliability is based on
> **all** pieces of software adhering a common standard, I am inclined to
> believe that new cryptographic algorithms introduced with anything less
> restrictive than "IETF Review" - such as "Specification Required" and "RFC
> Required" - does not sufficiently prevent altering the interoperability of
> the DNS.
>
> Why do you feel that DNSSEC has requirements stronger than other IETF
> security prot0cols such as TLS, IPsec, S/MIME, and so on?
>

<mglt>
If I understand clearly the comment, it seems to say that TLS ( for example
) is using RFC Required and that DNSSEC should do the same. Quickly going
through RFC 8447, I cannot find "RFC Required", so I am wondering if you
have a specific registry in mind. As far as I can see, the TLS cipher suite
registry requires Standard Action to set Recommended to "Y" and
Specification Required otherwise. As a result, leaving it to Standard
Action seems better aligned with what TLS does for "Recommended".

My motivation for not lowering the requirement is based on the specificities
of DNS, that is the DNS is a system handles a global shared resource - I
think that is what I was trying to say in my first sentence. I am not aware
of shared resources handled by the protocols you mentioned. DNS is part of
the Internet architecture and an interoperability issue with DNS is an
Internet infrastructure concern. A resolver not resolving .example affects
all its worldwide clients willing to connect to any host in .example. An
interoperability issue associated with the other security protocols being
mentioned is an issue between one sender and one receiver. This seems to me
less than an issue for the Internet.

Olafur comes with additional differences between DNSSEC and other security
protocols.
</mglt>

>
> > This is likely to result in the introduction of potentially weak - and
> unmanageable - cryptography, a fragmentation of the DNS name space, as well
> as the introduction of policy matters within the IETF.
>
> How would that happen? The developers of DNSSEC signing and validating
> software are intelligent, thoughtful people.
>
> <mglt>
If I understand your comment you seem to say that interoperability is
overall provided by the DNSSEC developers as opposed to the IETF. In
particular, developers will take the responsibility to make sure they all
pick the same subset of crypto to ensure interoperability. If that is
correct, it seems hard to explain that a resolver will not resolve some
domains, and believe this is the role of the IETF instead is to provide
such guidance.
</mglt>


> > Typically, some code points will be qualified as **standard** while
> others will be **non-standard**. This may put the IETF in a position to
> define that the trust of community C1 in algorithm A1 is non-standard while
> the trust of  community C2 in algorithm A2 is standard.
>
> Exactly right. DNSOP has already done that by adopting the GOST standard,
> which is only of interest to Russia (and maybe a small number of other
> countries). GOST is a standard *only* for DNSSEC, not for the other IETF
> security standards, which seems quite out of balance.
>
> <mglt>
My comment was that the specificities of DNS make code point assignment not
only technical but potentially raise some policy issues. It seems important
to be well aware of this and - in my opinion - avoid taking that path.
Your comment seems to say that GOST is a Standard for DNSSEC which is
unfair as this is not the case for other protocols and that GOST is only of
interest by some specific countries.
As mentioned earlier, DNSSEC has its own specificites that makes it
different from other protocols. Typically, your comment seems to say that
the use of GOST will be limited to the boundaries of a subset of countries.
I think this is misleading as this is, in fact, used by anyone (worldwide)
willing to access a web site associated with those countries/communities
(under .ru, among others). I do see this as a fragmentation and believe we
should avoid this as much as it is possible. More specifically, I expect
that resolvers will have to implement anything that is used, which - again
in my opinion - makes the requirement for anything non standard useless.
</mglt>


> > I believe we should avoid this path.
> > In addition, I also believe that "Standard Track" is the appropriated
> status. While a call for adoption of a cryptographic algorithm with a
> "Standard Track" asks pretty clearly the community on whether they are
> willing to see that algorithm being deployed. The same call for adoption
> with another status is less clear and people may not feel concerned which
> will make it harder to judge the consensus. It is also envisioned that
> calls for adoption will have an extra round of discussion over the status
> which I am not sure is necessary.
> >
> > As a result, I am inclined to believe we should not adopt
> draft-hoffman-dnssec-iana-cons and we should re-evaluate RFC6014.
>
> What has changed since DNSOP discussed and adopted RFC 6014 that would
> make us want to do that?
>
> <mglt>
Looking at the call for adoption of RF6014 [1] this seems a legitimate
question. On my side, I had not reviewed RFC 6014 but would have probably
come with similar comments if the call for adoption would have been today.
[1] https://mailarchive.ietf.org/arch/browse/dnsext/?q=dnssec-alg
-allocation&gbt=1
</mglt>


> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Daniel Migault
Ericsson