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

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Sep 2021 10:41:04 -0400

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

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 15 Sep 2021 19:45:28 +0200

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.

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

--Vladimir

---

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

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

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

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