Subject: [DNSOP] Algorithm implementation recommendations in 8624

From: Tim Wicinski <[email-masked]>
Date: Tue, 16 Jun 2020 18:35:17 -0400

All

The more time I spend referring to the implementation recommendation
table in 8624

https://www.rfc-editor.org/rfc/rfc8624.html#page-5

The more time I wonder if there is a way to extend
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

to add signing/validation recommendations.  This seems "hard" from the
world of IANA, but I'm not an expert.

Any opinions or suggestions?

tim

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 17 Jun 2020 06:30:12 +0000

On 17 Jun 2020, at 00:35, Tim Wicinski <[email-masked]<mailto:[email-masked]>> wrote:

All

The more time I spend referring to the implementation recommendation table in 8624

to add signing/validation recommendations.  This seems "hard" from the world of IANA, but I'm not an expert.

What strikes me is that IANA has no reference to RFC 8624 and that IANA still seems to consider SHA-1 and GOST to be algorithms to be used.

Mats

---
Mats Dufberg
[email-masked]<mailto:[email-masked]>
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 17 Jun 2020 14:55:31 +0200

On 6/17/20 8:30 AM, Mats Dufberg wrote:
>> I wonder if there is a way to extend 
>> to add signing/validation recommendations.  This seems "hard" from
>> the world of IANA, but I'm not an expert.
>
> What strikes me is that IANA has no reference to RFC 8624 and that
> IANA still seems to consider SHA-1 and GOST to be algorithms to be used.

According to that last RFC, GOST in particular MAY be supported in
validators, but there are others.  Maybe the "Zone Signing" column in
the registry is not meant to represent whether an algorithm has been
obsoleted but just the purpose?  Or did "we forget" to add IANA section
into that RFC?  (I'm no good around these process-related knowledge.)

In any case, it would be nice from my perspective if the table could
contain... basically the table from the RFC.

--Vladimir

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Jun 2020 14:18:26 -0400 (EDT)

> to add signing/validation recommendations.  This seems "hard" from the world of IANA, but I'm not an expert.

We did the same at IPsec, where we are instructing IANA to do something
similar:

https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard-04#section-6

    This document instructs IANA to mark all IKEv1 registries as
    DEPRECATED.

    Additionally, this document instructs IANA to add an additional
    Status column to the IKEv2 Transform Type registries and mark the
    following entries as DEPRECATED:

    [...]

> What strikes me is that IANA has no reference to RFC 8624 and that IANA still seems to consider SHA-1 and GOST to be algorithms

Technically, IANA does not "consider" anything. They just assign
numbers. I agree it is helpful to list more information to the latest
relevant RFCs in the IANA section though. But the text from 8624
does not map cleanly into the existing registry.

We have had a similar discussion in IPsec on how much we want to be
in the RFC and how much we want to have in the IANA registry. People
have different views.

> According to that last RFC, GOST in particular MAY be supported in validators, but there are others.  Maybe the "Zone Signing" column
> in the registry is not meant to represent whether an algorithm has been obsoleted but just the purpose?  Or did "we forget" to add
> IANA section into that RFC?  (I'm no good around these process-related knowledge.)

I think it refers to the DNSKEY flag, but I admit I find the colum for
Zone Signing and "Trans. Sec." confusing - but I'm not a DNS
implementer.

> In any case, it would be nice from my perspective if the table could contain... basically the table from the RFC.

It is something we should discuss for the 8624bis document.

Paul