[DNSOP] Re: Mohamed Boucadair's Discuss on draft-ietf-dnsop-must-not-sha1-06: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Wes, 

Thanks for the follow-up.

Apologies for the delay to reply but I wanted to make first review mentioned in your reply.

I'm confident we will clear remaining points before the telechat.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Wes Hardaker <[e-mail]>
> Envoyé : mardi 22 avril 2025 00:20
> À : Mohamed Boucadair via Datatracker <[e-mail]>
> Cc : The IESG <[e-mail]>; BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>; draft-ietf-dnsop-must-not-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-dnsop-must-
> not-sha1-06: (with DISCUSS and COMMENT)
> 
> 
> Mohamed Boucadair via Datatracker <[e-mail]> writes:
> 
> Hiya,
> 
> Responding to your points inline:
> 
> > # Process Check
> >
> > De we need to do anything given that some of the work we are
> updating
> > falls under pre-5378?
> 
> We don't think so.  Specifically this document has no pre-existing
> text that we're copying from, so don't believe that the pre-5378
> stuff applies.  This document is entirely written from scratch as
> new.

[Med] Thanks for confirming.

> 
> > # Authoritative source for recommended DNSSEC Algos
> >
> > I was naively expecting that we have a document where we say that
> the
> > authoritative reference for recommended values is the IANA
> registry,
> > not individual RFCs?
> >
> > Do we have such document? If so, the explicit updates in the
> draft may
> > not be required.
> 
> The IANA registry table is the table we are trying to update which
> holds the registry values that indicates the standards level.  You
> may want to review our companion document [1] that progressing at
> the same time that moves all recommendations into the IANA table
> because documenting the list only in an RFC turned out to be
> problematic.  This document
> (must-not-sha1) thus sets the levels to match the recommendation
> values for implementation and deployment.
> 
> [1]:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-rfc8624-
> bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb42d87bdc7e5
> 4efd4d0908dd8122a7f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38808708050608236%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D
> %7C0%7C%7C%7C&sdata=BHDICVxLE%2BnPdj0KnElSFPAGdou9UYxsIqc8FUKZoOQ%3
> D&reserved=0

[Med] Now that I reviewed [1], and given that the authoritative source will be the IANA registry for now, I think that it is cleaner to remove the update thing but depend on the registry as set by [1].

> 
> > # BCP237 Umbrella
> >
> > As a big fun of BCP237, I wonder whether we should make this more
> > visible in our DNSSEC "roadmap" documentation and list this
> document
> > under the BCP237 umbrella?
> 
> So BCP237 currently only has one document within it (RFC9364).  I
> think if we added every future DNSSEC document to the BCP it would
> likely get overwhelming.  I would argue that whether or not and how
> often we should update BCP237 is a good discussion for the WG as a
> whole, but it's outside the scope of this particular document
> (set).  But that's very much IMHO.

[Med] I consider this point closed. I like the concrete action taken by Paul. Thanks.

> 
> > -----------------------------------------------------------------
> -----
> > COMMENT:
> > -----------------------------------------------------------------
> -----
> >
> > # Expand DNS Public Key (DNSKEY) and resource record digital
> signature
> > (RRSIG) in the abstract and introduction.
> 
> Done.  I'm not sure this is standard convention so we'll see if
> there are others comments about this.
> 

[Med] Thanks


> > # Introduction
> >
> > (1) Reword for better clarity
> >
> > s/The security of the SHA-1/The security protection provided by
> the
> > SHA-1
> 
> Done

[Med] Thanks 

> 
> >
> > (2) Inappropriate citation
> >
> > CURRENT: "DNSSEC [RFC9364] originally [RFC3110].."
> >
> > I would not cite this specific RFC as this may imply that it is
> RFC
> > that «made extensive».
> 
> We could not quite understand what you wanted here, as both
> references made sense to us.  Are you saying the RFC9364 or RFC3110
> should be removed?

[Med] the comment is about removing RFC9364 citation at this place. The following text does not match with what RFC9364 syas. Better to avoid the confusion. Thanks.

> 
> > CURRENT: "Readers are encouraged to consider .."
> >
> > Not sure to parse the intent here? Do you mean implementers?
> Operators? Both?
> > Please reword accordingly.
> 
> Good point, changed to "operators".

[Med] ACK

> 
> > (4)
> >
> > CURRENT: "has been removed from some systems"
> >
> > May cite an example
> 
> I think the references would all be external and likely changing,
> thus we can't likely quote them directly.  The one that has been
> talked about the most is RedHat's OSes, but I don't think calling
> them out in this document would be appropriate.

[Med] Fair. Thanks

> 
> > # Section 2:
> >
> > (1)
> >
> > CURRENT: "Validating resolver implementations MUST .."
> >
> > Please add a reference to
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> atatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9499%23section-
> 10&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb42d87bdc7e54efd
> 4d0908dd8122a7f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63880
> 8708050635059%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
> %7C%7C%7C&sdata=Qg0PJKGKnOZS2wClDroBGz%2B2hnHTcGgjFHl6pV5xTSc%3D&re
> served=0.
> 
> done
> 

[Med] Thanks.

> > (2)
> >
> > CURRENT: "more security strict environments.."
> >
> > Can we characterize this? Or provide an example? Thanks.
> 
> Not likely, as it's a highly subjective discussion that warrants an
> RFC or academic or industry white paper in itself.  The security
> community will always disagree on the right level of hammer for the
> right job.

[Med] :-)

> 
> > # IANA Considerations
> >
> > CURRENT: "IANA is requested to set the "Use for DNSSEC Signing"
> column ."
> >
> > There is no such column. I guess you meant "Zone Signing"?
> 
> This document is modifying the table as being modified by the
> previously discussed companion document above [1].  That document
> introduces the new columns that we're now changing.  This document
> is, essentially, the first test of that new process.

[Med] ACK.

> 
> > You have many references that are listed but not sued (RFC4033,
> > RFC4509, RFC5702, etc.). Please check these.
> 
> Done.

[Med] Thanks.

> 
> > Also, there is a problem in how the references are classified.
> For
> > example, you list "RFC8174" as informative, while this should be
> > normative. Likewise, "RFC3110" is listed as normative, while it
> should be informative.
> 
> 8174 has been fixed (thanks)

[Med] ACK

> 
> 3110 is the basis for what we're modifying as recommended, so IMHO
> it should be normative (but is not a hill I'll die on either).
> 
> --
> Wes Hardaker
> USC/ISI
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.