[DNSOP] Review of draft-ietf-dnsop-rfc5011-security-considerations-13, was Re: [Ext] IETF meeting prep and what

[Paul Wouters <[e-mail]>]

On Fri, 18 Jun 2021, Paul Hoffman wrote:

>>> I propose replacing rfc5011-security-considerations
>>
>> I keep meaning to republish it with Olafur's suggested reduced title
>> (since it's really describing just one problem).  But it's unlikely to
>> get published as an RFC due to lack of consensus after a long drawn out
>> conversation where most of the WG stopped reading due to the harsh
>> language of some messages.
>
> For those who don't remember, the lack of consensus was based on too few people speaking to support the document after one WG member kept harshly objecting to some of the wording. This happened well WG Last Call was finished. The chairs decided to kill the document rather than deal decisively with the one obstructionist WG participant.
>
>> It can probably be dropped from the active
>> list because of this.
>
> I would like to see the document, which we all already agreed on, moved to IETF Last Call instead.

Background can be read here:

https://www.mail-archive.com/[e-mail]/msg17749.html

Since then, -13 was published which clarifies the update to RFC 7583 and
made the document Informational:

https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-13.txt

I used this opportunity to review the document again.

Probably Section 1.2 needs an update because it refers to ICANN plans of 2018. Even if the
plans are unchanged, the date should be bumped to reflect that.

Section 4.2 states:

    2.  Sign the revoked DNSKEY with itself.

This should clarify that we are talking about signing a DNSKEY RRset,
not a single RR.

Similar in 5.1.1:

 	considering the RRSIGs that cover the DNSKEYs in this document.


s/signs the zone's key set with/signs the zone's DNSKEY RRset with/

(more places with "key set" of similar phrasing should be cleared up)

Section 6.1.7 confuses me a bit as it defines a numResolvers variable,
and uses that to calculate an acceptable new timing period. To me it
feels that number of resolvers should not matter, as we should stick
to the formal time where all resolvers are either updated or no longer
updatable. This arguments also bleeds into Section 6.2 where it is used
indirectly.

Appendix A should be updated as well:

 	In 2017 and 2018, ICANN expects to [....]



Assuming Section 6.1.7 is right and just needs a little bit more
explanation, once the above mentioned nits are resolved, I think
this document is ready to move forward. I will leave it up to the
WGchairs et all. to decide on whether that is another WGLC or IETF LC.

Dropping this document would be a mistake and possibly lead to
implementation mistakes.

Paul