Subject: [netmod] MD5 in ianach ex-RFC7317

From: tom petch <[email-masked]>
Date: Tue, 9 Feb 2021 12:33:31 +0000

MD5 has long been deprecated as in RFC6151, RFC8573(NTP).

The NTP YANG I-D, ntp-yang-data-model, imports ianach without any constraint and so goes against RFC8573.

I think we should update ianach to deprecate MD5 by adding a status clause.  This is a permitted update per YANG and the module is Expert Review so I believe that with the consensus of the NETMOD WG, IANA could be asked to add 'status deprecated' to MD5.

Thoughts?

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Feb 2021 17:06:38 +0000

Hi Tom,

> I think we should update ianach to deprecate MD5 by adding a status clause.  This is a permitted update per YANG and the module is Expert Review so I believe that with the consensus of the NETMOD W…

I agree, but it takes an I-D to do the update, yes?

K.

---

From: tom petch <[email-masked]>
Date: Tue, 9 Feb 2021 17:10:50 +0000

From: Kent Watsen <[email-masked]>
Sent: 09 February 2021 17:06

Hi Tom,

<tp>
I don't see why; the registry is expert review and we are doing a change that comes under permitted changes for a YANG module, ie a status change.

Tom Petch
K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Feb 2021 18:12:23 +0100

> I agree, but it takes an I-D to do the update, yes?

I believe the process is that someone submits an update request to
IANA and IANA will then contact the Expert for Review and then the
Expert does whatever she does. "The designated expert is not required
to personally bear the burden of evaluating and deciding all requests,
but acts as a shepherd for the request, enlisting the help of others
as appropriate." (RFC 5226, BCP 26)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: tom petch <[email-masked]>
Date: Tue, 9 Feb 2021 17:28:56 +0000

From: Juergen Schoenwaelder <[email-masked]>
Sent: 09 February 2021 17:12

<tp>
I agree but think the Expert Reviewer, as appointed by IANA, would be helped along their way if they had the consensus of the NETMOD WG in favour of this.

Tom Petch

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Feb 2021 17:47:28 +0000

> I don't see why; the registry is expert review and we are doing a change that comes under permitted changes for a YANG module, ie a status change.

My understanding is that a publication of a draft altering an IANA registry will trigger an “expert review”, if that registry was created with the update-policy set that way. The draft itself doesn’t request an expert review, the expert review happens in the background. I’m not familiar with this being done without an I-D, in order to show WG consensus. 

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Feb 2021 20:10:54 +0100

> My understanding is that a publication of a draft altering an IANA registry will trigger an “expert review”, if that registry was created with the update-policy set that way. The draft itself doesn…

My understanding is that IANA reviews all documents during the
publication process and while performing this review they will notice
that something is requested to be added/changed in a registry that
requires expert review and then they will go and run the procedure.

My understanding is this is _one_ way to make a request to IANA but
not the only way to make a request to IANA.

The more interesting bit is what IANA has to say about this registry:

iana-crypt-hash YANG Module 	RFC 7317
		     		Expert Review (Expert: Unassigned)

Perhaps we should focus more on finding a volunteer willing to take
the role of the Designated Expert...

/js

---

From: tom petch <[email-masked]>
Date: Wed, 10 Feb 2021 11:24:29 +0000

From: netmod <[email-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Sent: 09 February 2021 19:10

<tp>
That is several steps ahead of us and, as and when it arises, that is the job of the IESG, not us. 

The first task, for us or for the NTP WG (who want it to happen) or ... is to reach a consensus on whether or not the module is fit for purpose, or whether it needs updating.

Tom Petch

/js

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: tom petch <[email-masked]>
Date: Wed, 10 Feb 2021 11:31:48 +0000

From: Kent Watsen <[email-masked]>
Sent: 09 February 2021 17:47

<tp>

<tp>
It happens in the TLS WG, for example, where the registries of security options are Expert Review and when an e-mail comes to IANA, which may be from outside the IETF, the reviewers raise it on the TLS list and if they are satisfied with the support, tell IANA to go ahead.

No I-D needed, no decision for the WG Chair to make.  The whole point of Expert Review is to have a process which is not as heavy-weight as a (Standards Track) RFC.

Tom Petch

K.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 10 Feb 2021 15:28:04 +0000

> It happens in the TLS WG, for example, where the registries of security options are Expert Review and when an e-mail comes to IANA, which may be from outside the IETF, the reviewers raise it on the…

Gotcha.  Reviewer raises on list and returns result to IANA.  No I-D needed.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 10 Feb 2021 16:15:23 +0000

> the role of the Designated Expert...

I'm aware that IESG made a designation in 2019, but it's not reflected here.  It appears to be just that IANA didn’t update the page, so I pinged them about that.

> The first task, for us or for the NTP WG (who want it to happen) or ... is to reach a consensus on whether or not the module is fit for purpose, or whether it needs updating.

This?
 
NEW:

     feature crypt-hash-md5 {
       status deprecated;
       description
         "Indicates that the device supports the MD5
          hash function in 'crypt-hash' values.";
       reference "RFC 1321: The MD5 Message-Digest Algorithm";
     }

And also:

     revision 2021-MM-DD {
       description
         “Deprecated the 'crypt-hash-md5’ feature.";
       reference
         "RFC 7317: A YANG Data Model for System Management";
     }

And publish the result as [email-masked]

Works for me.

Kent

---

From: tom petch <[email-masked]>
Date: Wed, 10 Feb 2021 16:46:59 +0000

From: Kent Watsen <[email-masked]>
Sent: 10 February 2021 16:15

<tp>

This?

NEW:

     feature crypt-hash-md5 {
       status deprecated;
       description

And also:

     revision 2021-MM-DD {
       description

And publish the result as [email-masked]<mailto:[email-masked]>

Works for me.

<tp>
Not quite for me.  The current version is that on the IANA website, RFC7317 is history at least for IANACH so I think that the YANG reference for the update should be to the IANA website.

Tom Petch

Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 10 Feb 2021 17:25:26 +0000

> On Feb 10, 2021, at 11:46 AM, tom petch <[email-masked]> wrote:
> 

Please provide OLD/NEW text.

FWIW, RFC8407 says:

   A "revision" statement MUST be present for each published version of
   the module.  The "revision" statement MUST have a "reference"
   substatement.  It MUST identify the published document that contains
   the module.

So what is the “document”?

    revision 2021-MM-DD {
      description
        “Deprecated the 'crypt-hash-md5’ feature per RFC 6151.";
      reference
        "RFC 6151:
             Updated Security Considerations for the MD5
             Message-Digest and the HMAC-MD5 Algorithms";
    }

But note that 6151 was published long before 7317 and, besides, it doesn’t “deprecate” MD5.

We can’t reference 8573 because it's NTP-specific.  Perhaps iana-crypt-hash is fine, and instead ntp-yang-data-model should be republished, augmenting in the desired “status” while referencing 8573.

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Feb 2021 18:32:16 +0100

RFC 8407:

4.  YANG Usage Guidelines

   Modules in IETF Standards Track specifications MUST comply with all
   syntactic and semantic requirements of YANG 1.1 [RFC7950].

The rule you quoted does not apply since we are talking about an IANA
document.

/js

---

From: tom petch <[email-masked]>
Date: Thu, 11 Feb 2021 12:51:49 +0000

From: Juergen Schoenwaelder <[email-masked]>
Sent: 10 February 2021 17:32
RFC 8407:

4.  YANG Usage Guidelines

<tp>

Yes.  This is the sort of detail that I would leave to IANA to sort out trusting them to come back as and when they want clarification.  I would start with a reference clause to the current version on the IANA website.  The weakness of this is that once IANA have performed the update, then the previous version will not be readily available, unlike RFC which last a long time but as I say, leave the detail to IANA.

Tom Petch
/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 11 Feb 2021 14:56:31 +0000

Hi Tom,

> I would start with a reference clause to the current version on the IANA website.  

Please propose specific text.

Thanks,
Kent // expert reviewer hat