On 15 Sep 2021, at 17:17, Daniel Migault wrote:
Hi Paul,
Thanks for the feedbacks, please see my responses.
Yours, Daniel
On Wed, Sep 15, 2021 at 6:24 PM Paul Hoffman <paul.hoffman@xxxxxxxx>
wrote:
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 draft provides the ability to register code points for non
standard
algorithms and I would like to understand how this non standard status
affects the interoperability compared to the standard ones. If it does
not
impact interoperability we should say and explain why.
As the draft clearly states, all DNSSEC algorithm types other than the
two in this draft already do not require standards track. This draft
just adds two more DNSSEC algorithm types to that list. I do not think
that this draft should explain the earlier IETF decisions to not require
standards track for those algorithms; those earlier RFCs already did as
much as needed.
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.
My comment is that the document should clarify how introducing a
nonstandard algorithm differs from a standard algorithm.
It does not, just as is the case for all DNSSEC algorithm types other
than the two in this draft.
In this case, the
expectation from a new hash introduced for an experiment and a new
hash
introduced to be fully interoperable in the DNS system are different
goals.
The document should explain how interoperability is affected by
introducing
a non standard algorithm.
We disagree. See above.
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.
Sure, before the choice was between having a code point defined as a
standard or no code point. This document makes it easier to get a code
point (RFC required which is good I think). On the other hand since
publication of the code point does not require a standard track
document,
this may end up in having code points defined as standard harder than
it is
today. Someone needing/willing a standard document may find this
situation
worse than what we have now. It would be good to understand clearly
the
implication of standard versus non standard and eventually explain why
non
standard is not an issue.
Why is this relevant for these two algorithm types, but not all DNSSEC
algorithm types other than the two in this draft?
If we take the following scenario: Country C is asking DNSOP to get
its
Algorithms A being published in a standard track document. The
document is
not adopted as a WG document, eventually it is redirected to ISE. I
think
country C should understand from that document what the implications
are.
Of course it could be anyone else than Country C and Country C is just
one
example.
This draft cannot predict the future of how the IETF will react to
requests for national algorithms. It would be irresponsible to make such
guesses.
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?
Maybe that is me but I cannot really see how the text below if non
standard
algorithms can be mandatory to implement.
"""
This document provides recommendations with respect to
mandatory-to-implement algorithms, algorithms so weak that they
cannot be recommended, and algorithms that are defined in RFCs
that are not on standards track.
"""
There is nothing in RFC 2026 (BCP 9) that says anything about the
relationship between standards track RFCs and mandating implementation.
If the IETF wants to make an algorithm mandatory-to-implement, or say
that cannot be implemented, that is the IETF's decision.
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.
The question was whether RFC 8624 can recommend or not a nonstandard
algorithm, not providing the recommendation itself.
After this draft is a standard, an update to RFC 8624 can make such a
recommendation. That is what Section 3 says.
--Paul Hoffman
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
