This is also undeployable. Saying “DO NOT VALIDATE WITH …” is deployable as you just get insecure out of the validator.   Turning off signing (as is directed) REQUIRES co-ordination with the parent zone to remove the DS records FIRST.  As a nameserver developer one can’t ship a server that doesn’t sign with an algorithm until after all the zones that were signed with that algorithm have been migrated away.   As the document itself states this is not the case. 
-- 
Mark Andrews

El 4 ago 2025, a las 8:21, Michael StJohns <[email protected]> escribió:


Hi Paul - 

On 8/3/2025 17:27, Paul Hoffman wrote:
On Aug 3, 2025, at 12:29, Michael StJohns <[email protected]> wrote:
On 8/3/2025 14:18, Paul Hoffman wrote:
Please note that this draft is already in the RFC Editor's queue, after having gone through WG Last Call, IETF Last Call, and IESG review.

Making changes after it has been approved would likely bring the document back to (at least) the WG for review, which seems like a bad idea. If there are no technical errors, leaving the document as-is will get it published and implemented sooner.
The thing is currently in Version Changed - Review Needed state.
Man, I hate to disagree so strongly with an old-timer, but look at the bottom of https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-sha1/: it really and truly is in the RFC Editor's queue. ("Version Changed - Review Needed" is an IANA status...)

You're correct, I read the wrong line.  Perhaps saying that next time without extraneous commentary would be sufficient?  

Hmm...  "EDIT" is before AUTH48 according to this: https://www.rfc-editor.org/about/queue/flowchart/   and "AUTH" seems to be one of the downstream states of "EDIT".

It would be useful to add a pointer to where "insecure" is defined as the generic meaning of "insecure" and the DNSSEC meaning are not identical.
As PaulW said, "insecure" is defined in BCP 237. Or, if you want to see two similar but different definitions, see Section 11 of BCP 219. Both are products of this WG.

The point is that "insecure" has a common meaning.  Which is different than the meaning in the general security domain.  Which is different than what DNSSEC means.   Nothing in this document indicates that "insecure" was meant to imply one of the 4 DNSSEC states from RFC4035, section 4.3. 

Consider that other than the DNSSEC nerds and geeks that mostly hangout in DNSOP, this was read (hopefully) by more than a few ADs and third parties who may not have considered that insecure did not mean what that would normally assume it meant.   Highlighting this meaning for implementers may have been helpful.

But at this point, its probably too late to clarify the meaning of "insecure" here and I agree with that so moving on.

Mike



--Paul Hoffman


_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to