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.
>> 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. 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.
>> 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.
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.
>> 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 theycannot be recommended, and algorithms that are defined in RFCs
that are not on standards track.
"""
>> 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.
--Paul Hoffman
Daniel Migault
Ericsson
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
