[DNSOP] Re: Roman Danyliw's No Objection on draft-ietf-dnsop-rfc8624-bis-09: (with COMMENT)

[Wes Hardaker <[e-mail]>]

Roman Danyliw via Datatracker <[e-mail]> writes:

Hi Roman,

Thanks for the notes. Comments inline

> I support the DISCUSS position of Mohamed Boucadair.
[...]

I'll duplicate the text we sent to him as well here.  Hopefully this
clears things up:

So this is where the confusion really comes in and one of the reasons we
wanted to change how this is done.  In the past there were two sources
of information that specified where you should look for current status
of a given algorithm:

1. the IANA tables (which you note deprecates GOST R 34.10-2001).
2. RFC8624 (which talks about implementation requirements and has GOST R
34.10-2001 still listed as MAY)

Thus, the WG decided to:

1. Update 8624 so it no longer contained the implementation guidance and
moved the requirements into the IANA table itself, to address this very
source of confusion.  To ensure that 8624bis would get through without
diving into a debate about particular algorithms, the WG concluded that
8624bis should not change any values at all from 8624 and should just be
about switching how things were done.

2. Issue future documents about changing the values could then be
created to actually make value changes once the IANA registry update was
complete.  The first two documents doing so are the must-not-gost and
must-not-sha1 documents.  These were intentionally written as separate
documents for two reasons:  A) because we didn't know if the WG would
actually want to change those values (IE, it was an independent
discussion) and B) to test the process of the new 862bis procedures.

Technically, the documents could be combined but the history is much
cleaner as 3 separate documents.  In our humble opinion, of course, and
is what the consensus was as well.


> ** Section 2.  What is the set of RFC2119 key words that are permitted?  The
> text already mentioned MUST, MUST NOT, RECOMMENDED, NOT RECOMMENDED and MAY.
> 
> -- SHOULD and SHOULD NOT were explained as equivalent to RECOMMENDED.  Does
> that mean that it shouldn’t be used?
> 
> -- Can SHALL/SHALL NOT be used?
> 
> -- Can OPTIONAL be used?

How does this sound:

    Only values of "MAY", "RECOMMENDED", "MUST NOT", and "NOT
    RECOMMENDED" may be placed into the "Use for DNSSEC Signing" and
    "Use for DNSSEC Validation" columns.  Only values of "MAY",
    "RECOMMENDED", "MUST", "MUST NOT", and "NOT RECOMMENDED" may be
    placed into the "Implement for DNSSEC Signing" and "Implement for
    DNSSEC Validation" columns.  Note that a value of "MUST" is not an
    allowed value for the two "Use for" columns.


> ** Section 2. The text never explicitly explains the semantics of the four new
> columns.  It has to be inferred from the name.

Where were you when RFC8624 was written which also doesn't specify what
the names then meant either?

I've added this text:

   Use for DNSSEC Delegation:  Indicates the algorithm's recommended
      usage for deployment in DS records by authoritative servers.

   Use for DNSSEC Validation:  Indicates the algorithm's recommended
      usage for validation in validating resolvers.

   Implement for DNSSEC Delegation:  Indicates the recommendation for
      implementing the algorithm within authoritative servers.

   Implement for DNSSEC Validation:  Indicates the recommendation for
      implementing the algorithm within validating resolvers.

> 
> ** Section 3.  What is the relationship between these new columns and the “Zone
> Signing” and “Trans. Sec.” columns?

The Zone Signing and Trans. Sec. columns still remain and is defined by
the original DNSSEC document.  They specify what types of cryptographic
processes the algorithms can be used for, but the new columns specifies
whether you should use them or not.

-- 
Wes Hardaker                                     
USC/ISI