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

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Sep 2021 17:47:30 -0400

Hi,

As Paul H. mentioned to me the document is in the last call, I am providing
my comments to the last call mailing list. I feel that my comments mostly
concern the security consideration sections.

Yours,
Daniel

On Wed, Sep 15, 2021 at 10:41 AM Daniel Migault <[email-masked]> wrote:

> Hi,
>
> I apologize for the late answer, but here are my comments regarding the
> draft.
>
> I believe the security considerations section needs to mention the
> interoperability issue if a hash algorithm is not widely supported by the
> resolvers. 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 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. I would like to
> understand why this cannot be a problem. For additional transparency,
> the document needs, in my opinion, additional clarifications. This
> includes  guidelines or criteria for algorithms to qualify as standard as
> well as the relation with rfc8624 that makes DNSSEC interoperable in terms
> of cryptography. 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.
>
> Yours,
> Daniel
>
>
>
> On Tue, Aug 24, 2021 at 3:07 AM Tim Wicinski <[email-masked]> wrote:
>
>> All
>>
>> The Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons ended
>> last week, and we've filtered through the comments both pro and con.
>>
>> We feel there is rough consensus to move this forward.
>>
>> thanks
>>
>> Benno/Suzanne/Tim
>>
>>
>> On Wed, Aug 4, 2021 at 11:29 AM Tim Wicinski <[email-masked]> wrote:
>>
>>>
>>> All
>>>
>>> This starts a Working Group Last Call for
>>> draft-ietf-dnsop-dnssec-iana-cons
>>>
>>> Current versions of the draft is available here:
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/
>>>
>>> The Current Intended Status of this document is: Standards Track
>>>
>>> Please review the draft and offer relevant comments.
>>> If this does not seem appropriate please speak out.
>>> If someone feels the document is *not* ready for publication, please
>>> speak out with your reasons.
>>>
>>> This starts a two week Working Group Last Call process, and ends on:  18
>>> August 2021
>>>
>>> thanks
>>> tim
>>>
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> --
> Daniel Migault
> Ericsson
>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Sep 2021 17:51:15 -0400

Hi Vladimir,

Thanks for the feedback. Please see my responses inline.

On Wed, Sep 15, 2021 at 1:45 PM Vladimír Čunát <[email-masked]>
wrote:

> On 15/09/2021 16.41, Daniel Migault wrote:
> > 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. I
> > would like to understand why this cannot be a problem.
>
> I'm sorry, I'm a bit confused about which nations would get standard
> algorithms.  Are P-256 and P-384 considered "national" crypto?  I know
> they're from NIST, but they seem widely popular outside USA.
> Technically we have old GOST algo(s) on standards track, though they are
> already obsolete in its nation, so those? Or some other (planned)
> algorithm I've missed?  Apart from that, I personally think that
> allowing "cheaper" allocations of algorithm numbers *reduces* this
> disparity/problem instead of making it worse, but perhaps I'm missing
> the essence of the issue.
>
> The reason I am mentioning the national algorithm is that these motivated
the support for lowering the barrier for a code point allocation at least
during the call for adoption. I was wondering if such nations would find it
acceptable to have their algorithm as non standard. I do not have any
specific example in mind and as far as I know GOST is standard [1] - This
was already the case during the call for adoption and I suppose it was
mentioned as an example.
I am pretty sure similar cases will show up in the future, so we should
try, as you mention, to reduce these disparities. If that is not seen as an
issue, that is good. In any case the issue there was non technical.

[1] https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/

> Interoperability could be mentioned for reference, though in practice
> having a standard does not necessarily help that much, e.g. Ed25519
> validation levels are still rather low after four years with standard
> and Ed448 is probably even worse:
> https://www.potaroo.net/ispcol/2021-06/eddi.html
>
> What I meant is that when a code point is adopted as a standard, there is
a commitment from most resolver developers to support it. Interoperability
is then provided when all resolvers are updated and it takes some time
(software life cycle management) for the system to provide
interoperability.
I agree with you that standard does not mean implemented by the resolver
but mostly because a standard algorithm may also be deprecated, and this is
why it seems to me useful to mention RFC8624 that defines the algorithms
that need to be implemented. In particular it would be good to know whether
non standard algorithms could be mandated by RFC8624 updates. If that is
not the case, as far as I understand it, non-standards are likely to never
be interoperable.
Ed* adoption shows that this takes more than 4 years to be deployed, but
its deployment status remains consistent with RFC8624.

As a result, if the software life cycle management time is long for a
standard algorithm, it is likely to take even longer to provide
interoperability (which I think is worth mentioning).  I also believe it is
helpful to have RFC8624 being referenced as which algorithm to implement
and deploy as opposed to relying on the status of the code point - which is
I think your point.

--Vladimir

-- 
Daniel Migault
Ericsson

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Sep 2021 15:24:06 -0700

This message relates to draft-ietf-dnsop-dnssec-iana-cons.

On 15 Sep 2021, at 14:47, Daniel Migault wrote:

>> 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

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.

>> 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,
>> 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
>> 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

We fully disagree about this draft saying anything about this. That is 
*exactly* what RFC 8624 is about.

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Sep 2021 20:17:45 -0400

Hi Paul,

Thanks for the feedbacks, please see my responses.

Yours, Daniel

> 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.

> 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.

> 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.

> 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.
"""
> *exactly* what RFC 8624 is about.

The question was whether RFC 8624 can recommend or not a nonstandard
algorithm, not providing the recommendation itself.

-- 
Daniel Migault
Ericsson

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Sep 2021 17:59:04 -0700

On 15 Sep 2021, at 17:17, Daniel Migault wrote:

>>>> interoperability issue if a hash algorithm is not widely supported 
>>>> by
>>>> the
>>>> resolvers.
>>

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.

> 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

We disagree. See above.

> 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?

> Of course it could be anyone else than Country C and Country C is just 

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.

>>>> well as the relation with rfc8624 that makes DNSSEC interoperable 
>>>> in
>>>> terms
>>>> of cryptography.
>>

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.

> 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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Sep 2021 21:33:25 -0400 (EDT)

> 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.

I agree with PaulH here, as the draft clearly states:

    The rationale for these changes is to bring the requirements for DS
    records and for the hash algorithms used in NSEC3 in line with the
    requirements for all other DNSSEC algorithms.

>>  nonstandard algorithm differs from a standard algorithm.

That would be the task of RFC 8624bis, not this draft. Although this
draft already does provide a general advise:

    and updates RFC 8624 to say that algorithms that are described in RFCs
    that are not on standards track are only at the "MAY" level of implementation
    recommendation.

A new "non standard" algorithm could only appear at the MAY level.
That is a strong hint that it is not wise to solely rely on it. If
it breaks, you get to keep both pieces. If one strongly feels it
should gain more support/momentum, go and push it through as standards
track document after the initiating non-standard publication.

I don't think this draft would enable unexpected unsafe deployments of
new algorithms.

> recommendation. That is what Section 3 says.

RFC 8624 can only recommend what it recommends in the document at
publication time. A successor to 8624, which would require going
through the working group on standards track, can recommend whatever
the working group decides at the time.

Paul

---

From: Daniel Migault <[email-masked]>
Date: Thu, 16 Sep 2021 07:29:51 -0400

> standards track for those algorithms; those earlier RFCs already did as
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.

> algorithm types other than the two in this draft?
see my first comment.

> requests for national algorithms. It would be irresponsible to make such

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

> that cannot be implemented, that is the IETF's decision.
Then this seems a good opportunity to clarify this.

> 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.

-- 
Daniel Migault
Ericsson

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Sep 2021 11:00:25 -0400 (EDT)

On Thu, 16 Sep 2021, Daniel Migault wrote:

> The concern is interoperability.

I think the real concern, that this document solves, is that if there
is a new algorithm some group wants to use for DNSSEC, that it can
be at least _specified_ in RFCs and registered in IANA registries,
be in standards track or experimental or informational. This document
ensures that. Right now, one could not specify an informational algorithm
completely, only partially, due to the inconsistent registration policies
for the related IANA Registries.

Once specified, whether something should or should not be mandatory to
implement (for validators or for signers) is up to RFC 8624bis. That
document would take into account operational concerns, as well as
cryptographic concerns, and interoperability concerns. For example,
it would like first try to promote (via MAY or perhaps SHOULD) that the
algorithm can be used/tested. Possibly it would then proceed to
to make validation a MUST before promoting the signers to SHOULD or
MUST.

> If previous RFC addressed it, then it should be ease to add a reference.

I believe the only reference needed is already there 8624. Possibly, one
could refer to the DNSSEC BCP document, RFC 6781. It has a section 3.4 on
"Cryptographic Considerations", but it does not really provide any advise
on the interoperability issue you are raising. Perhaps you could review
6781 and if you think your concern warrants it, propose starting a draft
on 6781bis ?

Paul

---

From: Daniel Migault <[email-masked]>
Date: Thu, 16 Sep 2021 20:56:47 -0400

Hi Paul,

Thanks for the response. Please see inline, this is exactly the
clarification I think the current document needs. Please see inline.

Yours,
Daniel

On Thu, Sep 16, 2021 at 11:00 AM Paul Wouters <[email-masked]> wrote:

> The two paragraphs you propose are **exactly** the kind of text I am
asking to be added to provide a clear path to anyone asking for the
registration of a new algorithm. It clarifies the impact associated to
standard and non standard code points, as well as that the
mandatory-to-implement are defined by 8624 independently from the status of
the code point. I also believe this could address interoperability - which
could even get removed from the security considerations as this is clearly
handled by 8624.

> I believe the only reference needed is already there 8624.

I agree 8624 is sufficient.

Possibly, one

-- 
Daniel Migault
Ericsson

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Sep 2021 15:47:26 -0400

> could even get removed from the security considerations as this is clearly

<ad hat>
I have read, and reread this document as well as RFC 8624, and think that
the current text is fine. I do think that if we write an RFC 8624bis (and I
hope we do), it can more fully discuss the implications and expectations
around the different code-points, as well as how best to introduce new
algorithms -- but, I don't think that that all belongs in *this* document.
This document "Revise[s] IANA Considerations for DNSSEC", and so I feel
that it should be kept focused on the IANA bits, not expanded into the
larger issues.
</ad hat>

W

> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 20 Sep 2021 17:06:22 +0200

On 15/09/2021 23.51, Daniel Migault wrote:
> I do not have any specific example in mind and as far as I know GOST 
> is standard [1] - This was already the case during the call for 
> adoption and I suppose it was mentioned as an example.

To clarify, that DNSSEC-standard GOST only uses crypto that's been 
obsolete for years, I believe.  And renewing this to the new GOST 2012 
versions was the main spark for the iana-cons draft. 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/