Re: [Last-Call] [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 15 Sep 2021, Paul Hoffman wrote:

On 15 Sep 2021, at 17:17, Daniel Migault wrote:


 This draft provides the ability to register code points for non standard
 algorithms and I would like to understand how this non standard status
 affects the interoperability compared to the standard ones. If it does not
 impact interoperability we should say and explain why.

As the draft clearly states, all DNSSEC algorithm types other than the two in this draft already do not require standards track. This draft just adds two more DNSSEC algorithm types to that list. I do not think that this draft should explain the earlier IETF decisions to not require standards track for those algorithms; those earlier RFCs already did as much as needed.

I agree with PaulH here, as the draft clearly states:

   The rationale for these changes is to bring the requirements for DS
   records and for the hash algorithms used in NSEC3 in line with the
   requirements for all other DNSSEC algorithms.

 My comment is that the document should clarify how introducing a
 nonstandard algorithm differs from a standard algorithm.

That would be the task of RFC 8624bis, not this draft. Although this
draft already does provide a general advise:

   and updates RFC 8624 to say that algorithms that are described in RFCs
   that are not on standards track are only at the "MAY" level of implementation
   recommendation.

A new "non standard" algorithm could only appear at the MAY level.
That is a strong hint that it is not wise to solely rely on it. If
it breaks, you get to keep both pieces. If one strongly feels it
should gain more support/momentum, go and push it through as standards
track document after the initiating non-standard publication.

I don't think this draft would enable unexpected unsafe deployments of
new algorithms.

 The question was whether RFC 8624 can recommend or not a nonstandard
 algorithm, not providing the recommendation itself.

After this draft is a standard, an update to RFC 8624 can make such a recommendation. That is what Section 3 says.

RFC 8624 can only recommend what it recommends in the document at
publication time. A successor to 8624, which would require going
through the working group on standards track, can recommend whatever
the working group decides at the time.

Paul

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux