From nobody Fri Mar 25 17:59:14 2022 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0173A112A for ; Fri, 25 Mar 2022 17:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.111 X-Spam-Level: X-Spam-Status: No, score=-5.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HK_RANDOM_ENVFROM=0.998, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G73O7E5gFjOG for ; Fri, 25 Mar 2022 17:59:07 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.rno.apple.com [17.179.253.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968DE3A1118 for ; Fri, 25 Mar 2022 17:59:05 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 22Q0nQQD022236 for ; Fri, 25 Mar 2022 17:59:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=aiCIgR/JVwVB1MyIRjMIYo5iBNZcXB74V72+LJioM0Q=; b=TehjXbcTyhFk8tXAGEkCjO8m70EnIEOGlr7z+XvTH4P0nBBLGjQMwEGd3ywrgG8QNn/s 1JvhBKdfrrXyVwEx0yh50/15wF7i6reXOR4dotzPArFW2AcEo1z8Otra6Iz1ZVVDQDU1 e9gcY8FhvNEaXAm5ck97jw38io37fAS0XRxWp8uEd/MUSAVMCGg8o/NiZ80g6uIRv7MT xnu1pPCcXJrFob+W/qkYPCLu/YXbltxAATHvOHri6d2Y+fT//gexHZktJKGjVXzYVi/w Yb8Vx69lwbDybI/unVe9+626b+zeGss7wE9EIrmjHOttoqYphWcBQG5PKo/cpayaH+Ec xg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 3ewb12qdby-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 25 Mar 2022 17:59:05 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) with ESMTPS id <0R9B004PVUQFI7F0@rn-mailsvcp-mta-lapp02.rno.apple.com> for dnsop@ietf.org; Fri, 25 Mar 2022 17:59:03 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) id <0R9B00F00UEO9C00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for dnsop@ietf.org; Fri, 25 Mar 2022 17:59:03 -0700 (PDT) X-Va-A: X-Va-T-CD: f4439a1f3baad66c778bad7f442511f1 X-Va-E-CD: 136051ad6e2994c9c3d9a6f2a1b5fc51 X-Va-R-CD: eef5b1a2f59bcea5dae2c7aeed674791 X-Va-CD: 0 X-Va-ID: f3cbdc80-5cfe-49b4-b14a-39b1f534244b X-V-A: X-V-T-CD: f4439a1f3baad66c778bad7f442511f1 X-V-E-CD: 136051ad6e2994c9c3d9a6f2a1b5fc51 X-V-R-CD: eef5b1a2f59bcea5dae2c7aeed674791 X-V-CD: 0 X-V-ID: 76851c7d-1268-47e7-b929-3d348df2a4f8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.850 definitions=2022-03-25_08:2022-03-24, 2022-03-25 signatures=0 Received: from smtpclient.apple (unknown [17.192.170.224]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) with ESMTPSA id <0R9B00V32UQF4300@rn-mailsvcp-mmp-lapp01.rno.apple.com> for dnsop@ietf.org; Fri, 25 Mar 2022 17:59:03 -0700 (PDT) From: Joey Deng Content-type: multipart/alternative; boundary="Apple-Mail=_188D71E9-001E-4F7F-89C0-2B6B81CF3567" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.0.1.1.13\)) Date: Fri, 25 Mar 2022 17:59:02 -0700 References: To: dnsop@ietf.org In-reply-to: Message-id: X-Mailer: Apple Mail (2.3693.0.1.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.850 definitions=2022-03-25_08:2022-03-24, 2022-03-25 signatures=0 Archived-At: Subject: Re: [DNSOP] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2022 00:59:12 -0000 --Apple-Mail=_188D71E9-001E-4F7F-89C0-2B6B81CF3567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 >=20 > 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. >=20 > 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. >=20 > 2.2 Cryptographic Algorithms and DNSSEC >=20 > 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. >=20 > 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 =E2=80=94 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/ = Thanks. -- Joey Deng > On Mar 24, 2022, at 4:26 PM, dnsop-request@ietf.org wrote: >=20 > [DNSOP] Call for Adoption: DNSSEC as BCP: > draft-hoffman-dnssec --Apple-Mail=_188D71E9-001E-4F7F-89C0-2B6B81CF3567 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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

=E2=80=94

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/

Thanks.

--
Joey Deng



On Mar 24, 2022, at 4:26 PM, dnsop-request@ietf.org wrote:

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

= --Apple-Mail=_188D71E9-001E-4F7F-89C0-2B6B81CF3567--