Re: [Last-Call] [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Sep 15, 2021 at 8:59 PM Paul Hoffman <paul.hoffman@xxxxxxxx> wrote:


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.
The concern is interoperability. If previous RFC addressed it, then it should be ease to add a reference.  As far as I see 6014 does not mention interoperability. That 6014 missed it the first time does not prevent us from addressing it now. The doc should position itself regarding this issue. 
>
>
>>>> 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?
see my first comment. 

> 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.
This is not about predicting the future, nor predicting the IETF reaction but considering how this document addresses a potential and plausible situation that seems quite close to [1]. In my opinion the document does not do it properly. 
[1] https://mailarchive.ietf.org/arch/browse/dnsop/?q=rfc5933-bis

>>>> 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.
Then this seems a good opportunity to clarify this.  

>>
>>
>>>> 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.
It is unclear to me what would prevent 8624 from making such a statement without the update and I think the document should state clearly standard / non standard are independent and not related to mandatory-to-implement - even if it is believed to have been said in the past.

--Paul Hoffman


--
Daniel Migault
Ericsson
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux