Subject: [DNSOP] SHA-1 DS algo in arpa. :)

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Sep 2021 11:28:04 -0400 (EDT)

Looks like for arpa., the DS records are:

arpa.			27247	IN	DS	42581 8 1 778606D9623F843F156E7D11ACBF815EB67AB516
arpa.			27247	IN	DS	42581 8 2 F28391C1ED4DC0F151EDD251A3103DCE0B9A5A251ACF6E24073771D7 1F3C40F9

Per our own recommendations, we should probanly ask for the SHA-1 record to be removed :)

This is hinted strongly at in 2006:

 	https://datatracker.ietf.org/doc/html/rfc4509#section-6.2

and even stronger via a MUST NOT in 2019's RFC 8624:

 	https://datatracker.ietf.org/doc/html/rfc8624#section-3.3

What's the process for requesting the SHA-1 based DS record deletation for .arpa?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Sep 2021 15:49:21 +0000

> 	https://datatracker.ietf.org/doc/html/rfc8624#section-3.3

RFC 8624 is implementation guidance, not deployment guidance. This WG discussed at length whether to include deployment guidance (particularly for weaker algorithms like SHA1) and concluded that we didn't want to do that. You should know this, given that you are co-editor of RFC 8624.

> What's the process for requesting the SHA-1 based DS record deletation for .arpa?

Did you first ask the administrators of the zone in question before sending this message to a grooup that has no administrative power over the zone?

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Sep 2021 12:04:51 -0400 (EDT)

> RFC 8624 is implementation guidance, not deployment guidance. This WG discussed at length whether to include deployment guidance (particularly for weaker algorithms like SHA1) and concluded that we…

It seems that if we tell implementors to MUST NOT implement, that it
would be very unwise to still create new records of this type? Unless
we specifically want to test being part of the long tail of obsolete
deployments as a standards body.

> Did you first ask the administrators of the zone in question before sending this message to a grooup that has no administrative power over the zone?

No, I used this group as the umbrella contact, as I assumed the
knowledgeable people are here. But it seems instead I found a grumpy
person who seems to know the process better than me but prefers
yelling into the cloud more than educating me.

Paul

---

From: Joe Abley <[email-masked]>
Date: Thu, 9 Sep 2021 12:12:52 -0400

Hi Paul (W),

On Sep 9, 2021, at 12:05, Paul Wouters <[email-masked]> wrote:

> knowledgeable people are here.

The IETF (well, the IAB) has administrative control over the contents of the ARPA zone. I do not know in practice whether this extends to the machinery of how the zone is provisioned. 

The operation of the zone is carried out by PTI, I think. It is distributed to its authoritative servers (which are also root servers) in a process that is similar in some respects to the way the root zone is managed.

I would drop a note to Kim Davies and ask his advice if you want to make some kind of progress. While it seems perfectly plausible to make this kind of change by way of a published RFC with IAB review, it's not at all clear to me that such a heavyweight approach is necessary. 

Joe

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 9 Sep 2021 12:27:35 -0400

Hi,

(Wes and Warren— cc’d as IAB and IESG members, do you guys have any further guidance?)

> On Sep 9, 2021, at 12:12 PM, Joe Abley <[email-masked]> wrote
> 

It might also be helpful to review RFC 3172 ("Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa”)”).

It doesn’t directly address “the machinery of how the zone is provisioned” but it does make some guidelines clear. 

Personally, I’d start with the IAB or IESG, if only to find out how much process was required to get it signed in the first place (I don’t recall, and can’t immediately find a reference). Maintaining compliance with the evolving spec for DNSSEC and crypto algorithms should not be too difficult, but will probably have to be documented somewhere and approved by the IAB.

Suzanne

---

From: Warren Kumari <[email-masked]>
Date: Thu, 9 Sep 2021 13:39:07 -0400

On Thu, Sep 9, 2021 at 12:13 PM Joe Abley <[email-masked]> wrote:

> >> Did you first ask the administrators of the zone in question before
> sending this message to a grooup that has no administrative power over the
> zone?
> >
> The IETF (well, the IAB) has administrative control over the contents of
> the ARPA zone. I do not know in practice whether this extends to the
> machinery of how the zone is provisioned.

>
> The operation of the zone is carried out by PTI, I think. It is
> distributed to its authoritative servers (which are also root servers) in a
> process that is similar in some respects to the way the root zone is
> managed.
>
> I would drop a note to Kim Davies and ask his advice if you want to make
> some kind of progress.

Yup. My personal view is that the IANA/PTI folk running this are friendly,
competent and helpful.

While it seems perfectly plausible to make this kind of change by way of a
> published RFC with IAB review, it's not at all clear to me that such a
> heavyweight approach is necessary.

Yup - I don't *know* of any requirements specifying anything as
detailed/operational as which DNSSEC algorithms should be used, when to
roll (these!) keys, etc. That sort of level of operational detail is
(AFAIK) left to PTI/IANA as the operator.
If I'm wrong, and there is a specific requirement, I'm guessing that PTI
could point at it, and it could then by updated -- but I'd assume that this
is simply 1: they haven't migrated yet because, well, they haven't yet, or
2: they've made a conscious decision based on operational knowledge of who
uses the zone, being cautious with critical infrastructure, etc.
Whatever the case, a simple email to Kim/IANA does sound like the right
first step.

W

>
>
>
> Joe
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 9 Sep 2021 14:09:14 -0400

> Whatever the case, a simple email to Kim/IANA does sound like the right

This reply might have been a bit hasty -- I don't actually know how tightly
this is specified, or who decided which DS algorithm should be used. It was
pointed out (off-list) that it seems like it should be the IAB as the TLD
operator. That sounds entirely reasonable... but the IANA acts in many ways
like a registry backend provider, so, well, perhaps it is them?!
At this point I have no idea, but 1: I do know it ain't me and 2: I suspect
that asking Kim and / or the IAB is probably a good start.

I'll now go hide under a rock, or at least get some lunch.
W

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Sep 2021 16:08:53 -0400

> Per our own recommendations, we should probanly ask for the SHA-1 record to be removed :)

Speaking of dogfood consumption, a year ago (Sep 2020) Wes and I reached
out to AMSL, suggesting algorithm rollovers to avoid use of deprecated
code points by ietf.org:

    https://stats.dnssec-tools.org/explore/?ietf.org

The discussion also included Robert Sparks, Russ Housley and Jay Daley.

This ultimately stalled around questions of providing detailed guidance
to AMSL on the rollover logistics, and IIRC Wes suggested that perhaps
the right risk/reward tradeoff is for ietf.org to temporarily (a few
days) go unsigned and then deploy new keys with algorithm 13 or 8.

This too should probably be addressed, between AMSL and the relevant
interested parties...

-- 
    Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 09 Sep 2021 14:37:21 -0700

Warren Kumari <[email-masked]> writes:

> This reply might have been a bit hasty -- I don't actually know how
> tightly this is specified, or who decided which DS algorithm should be
> used.

I'm not personally sure how the algorithms/other-properties are picked
for the IANA zones.  I can certainly ask the IAB to make a request to
IANA to change things, and it does seem like dropping DS/SHA-1 is a
reasonable thing to ask.  I don't think it needs a specification (RFC)
or anything -- we don't specify operational parameters much (nor do I
think we should).
-- 
Wes Hardaker
USC/ISI