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, dnsop-requ...@ietf.org wrote: > > [DNSOP] Call for Adoption: DNSSEC as BCP: > draft-hoffman-dnssec
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
