This message relates to draft-ietf-dnsop-dnssec-iana-cons.
On 15 Sep 2021, at 14:47, Daniel Migault wrote:
I believe the security considerations section needs to mention the
interoperability issue if a hash algorithm is not widely supported by
the
resolvers.
Could you explain why this is important for this draft but not, say, in
every draft that introduces a new hash algorithm? That is, it would be
good if you could propose specific language that ties the
interoperability concerns for a new hash algorithm to security.
This, in my view, can potentially affect the DNS system, and I
believe some text should try to limit non standard algorithms to very
specific deployment - including experimentation.
I'm still not sure what you are asking. *Any* new hash/signature
algorithm, regardless of whether they are on standards track, affects
the DNS due to their newness.
I believe that for experimentation the draft is helpful. Outside
experimentation, especially for national algorithms, this will lead
to
nations having their algorithms qualified as standard while other
nations
having their algorithms qualified as non standard.
This draft does not change the ability of a proposer of a new algorithm
to get on standards track. As the title says, it is only about the IANA
registry. If you have a concern about national algorithms and standards
track, those concerns should go to the IESG, the maintainers of the
standards track.
I would like to
understand why this cannot be a problem.
It is not a problem because this draft does not affect the track that
algorithms use. The WG chose to have all algorithms published as RFCs
the same: they can all go into the IANA registry.
For additional transparency,
the document needs, in my opinion, additional clarifications. This
includes guidelines or criteria for algorithms to qualify as
standard
It is unrelated to that. I disagree with the idea that this document
needs to list all the things that it is not related to.
as
well as the relation with rfc8624 that makes DNSSEC interoperable in
terms
of cryptography.
Section 3 of this draft is all about the relation to RFC 8624. Can you
be specific about what needs to be clarified?
More specifically it should clarify that standard
algorithms may or may not be recommended as well as whether non
standard
algorithms may or may not be recommended.
We fully disagree about this draft saying anything about this. That is
*exactly* what RFC 8624 is about.
--Paul Hoffman
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
