Subject: Re: [DNSOP] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec

From: Joey Deng <[email-masked]>
Date: Fri, 25 Mar 2022 17:59:02 -0700

Hi,

A possible format issue:

>    [RFC6840] brings a few additions into the core of DNSSEC.  It makes
>    NSEC3 [RFC5155] as much a part of DNSSEC as NSEC is.  It also makes
>    the SHA-2 hash function defined in [RFC4509] and [RFC5702] part of
>    the core as well. # Cryptographic Algorithms and DNSSEC
> 
>    Cryptography improves over time, and new algorithms get adopted by
>    various Internet protocols.  Two new signing algorithms have been
>    adopted by the DNSSEC community: ECDSA [RFC6605] and EdDSA [RFC8080].
>    The GOST signing algorithm [RFC5933] was also adopted, but has seen
>    very limited use, likely because it is a national algorithm specific
>    to a very small number of countries.
> 
>    Implementation developers who want to know which algorithms to
>    implement in DNSSEC software should refer to [RFC8624].  Note that
>    this specification is only about what algorithms should and should
>    not be included in implementations: it is not advice for which
>    algorithms that zone operators should and should not sign with, nor
>    which algorithms recursive resolver operators should or should not
>    validate.

Based on the context, the format should probably be:

>    [RFC6840] brings a few additions into the core of DNSSEC.  It makes
>    NSEC3 [RFC5155] as much a part of DNSSEC as NSEC is.  It also makes
>    the SHA-2 hash function defined in [RFC4509] and [RFC5702] part of
>    the core as well.
> 
> 2.2 Cryptographic Algorithms and DNSSEC
> 
>    Cryptography improves over time, and new algorithms get adopted by
>    various Internet protocols.  Two new signing algorithms have been
>    adopted by the DNSSEC community: ECDSA [RFC6605] and EdDSA [RFC8080].
>    The GOST signing algorithm [RFC5933] was also adopted, but has seen
>    very limited use, likely because it is a national algorithm specific
>    to a very small number of countries.
> 
>    Implementation developers who want to know which algorithms to
>    implement in DNSSEC software should refer to [RFC8624].  Note that
>    this specification is only about what algorithms should and should
>    not be included in implementations: it is not advice for which
>    algorithms that zone operators should and should not sign with, nor
>    which algorithms recursive resolver operators should or should not
>    validate.

Since the description above mainly focuses on the new cryptography adopted by DNSSEC, I think it would make more sense to use title like:

Additional Cryptographic Algorithms in DNSSEC

—

During my reading of DNS and DNSSEC, I found another RFC (RFC 7129) very helpful in understanding the motivation from NSEC to NSEC3, besides RFC 5155, but it is not listed in the draft above (maybe because it is for informational purposes?).
https://datatracker.ietf.org/doc/rfc7129/ <https://datatracker.ietf.org/doc/rfc7129/>

Thanks.

--
Joey Deng

> On Mar 24, 2022, at 4:26 PM, [email-masked] wrote:
> 
> [DNSOP] Call for Adoption: DNSSEC as BCP:
> 	draft-hoffman-dnssec

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 26 Mar 2022 01:21:40 +0000

> A possible format issue:

Thanks! That will be fixed in the next version.

> Additional Cryptographic Algorithms in DNSSEC

Yes, great.

> https://datatracker.ietf.org/doc/rfc7129/

While RFC 7129 is interesting for understanding the protocol, it is background material and maybe not really part of the protocol itself or an extension to the protocol itself. I'm not sure where it would fit into this document.

--Paul Hoffman

---

From: Peter Thomassen <[email-masked]>
Date: Tue, 29 Mar 2022 14:47:11 +0200

> While RFC 7129 is interesting for understanding the protocol, it is background material and maybe not really part of the protocol itself or an extension to the protocol itself. I'm not sure where i…
If

    The purpose is to introduce all of the RFCs in one place so
    that the reader can understand the many aspects of DNSSEC.

(taken from the abstract),

then including background material that helps understanding may be the right thing to do, perhaps in a separate section (e.g. "Additional non-normative documents" between Sections 3 and 4).

Otherwise, perhaps the purpose should be re-stated as to emphasize collecting only all pieces of the protocol specification.

I generally support this draft, and am willing to contribute review comments, perhaps editorial PRs etc.

Best,
Peter

-- 
https://desec.io/