Subject: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage

From: "Salz, Rich" <[email-masked]>
Date: Sat, 12 Aug 2017 21:58:30 +0000

At the IETF meeting last month there was strong consensus to have MUST NOT for both generate and verify using SHA-1.  The discussion on the list had one major participant opposed, who removed their objection once they understood there were two separate documents.

Therefore, we are entering a one-week WG last call.

(Seth, please start preparing your shepherd writeup :)

On 8/12/17, 5:55 PM, "IETF Secretariat" <[email-masked]> wrote:

    The IETF WG state of draft-ietf-dcrup-dkim-usage has been changed to "In WG
    Last Call" from "WG Document" by Rich Salz:
    
    https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 Aug 2017 11:34:20 -0700

On Sat, Aug 12, 2017 at 2:58 PM, Salz, Rich <[email-masked]> wrote:

> At the IETF meeting last month there was strong consensus to have MUST NOT
> for both generate and verify using SHA-1.  The discussion on the list had
> one major participant opposed, who removed their objection once they
> understood there were two separate documents.
>

Getting caught up after a long post-Prague vacation and recovery period.

The content and intent seem fine to me.  However, I was asked this after
the meeting in Prague as to form, in the spirit of "it's not done until you
can no longer remove things" or however that aphorism goes:

This document will be shown as "updates RFC6376".  Is replacing text in
RFC6376 the right way to do this?  Or would that not be better left to an
actual replacement document?  That is, why not just say "MUST NOT
sign/verify with rsa-sha1", change the state of "sha1" to obsolete, change
the minimum key size to 1024, and stop?  In particular, is it necessary to
render "a=rsa-sha1" syntactically invalid by removing it from the ABNFs, or
replace all of a section when only a couple of numbers are being tweaked?

Otherwise this seems ready to go.

-MSK, participating

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2017 21:20:32 -0000

In article <CAL0qLwaB8mdCbYjbzr6T3A5hQw3GnixuB=[email-masked]> you write:
>the minimum key size to 1024, and stop?

Having finally reread the draft, I agree, don't update the syntax.

It's fine if a verifier syntactically recognizes rsa-sha1 so long it
doesn't consider the signature to be valid.  Perhaps it could provoke
an SMTP response like 

  554 5.7.20 Fix your signatures if you want people to accept your mail.

Also, I think the status for dead codes is "historic" rather than
"obsolete" but that's up to IANA to make it consistent with other
registries.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 13 Aug 2017 17:25:50 -0400

> Otherwise this seems ready to go.

The draft has been this way from the beginning, so I find it a bit surprising 
to see this in last call when you've reviewed this more than once before, but 
oh well.

I updated the ABNF in the draft because I think if we are going to kill it, we 
should kill it absolutely dead.  What is the benefit of retaining obsolete 
features that are MUST NOT use in the ABNF?

In terms of the structure of the draft, I wrote it this was so it's very clear 
what is being updated.  This has been discussed a bit, but I don't think 
anyone really objected so far.  I find it's common in IETF documents to see 
one document updates another, but then it's hard to really tell everything in 
the original document that's affected by the update.  This is an attempt to be 
clear about that.

That's why, but I may be the only one that feels that way.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2017 22:35:30 -0000

>features that are MUST NOT use in the ABNF?

Recognize them and ridicule people who are still using them?

On a slightly more pragmatic note, leaving them in the ABNF makes it
less likely that someone later will add something that conflicts.  I
realize that the chances of adding something else named sha1 are
pretty low, but who knows what strangeness may happen a decade from
now.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 Aug 2017 18:18:12 -0700

> to see this in last call when you've reviewed this more than once before,

I don't see why that's relevant, but OK:

The suggestion was made to me in person after the meeting in Prague, and
the more I think about it, the more I think it's worth the WG's
consideration.

> features that are MUST NOT use in the ABNF?

I think the intent is to reject those signatures as no longer acceptable,
not render them syntactically invalid.

In terms of the structure of the draft, I wrote it this was so it's very
> clear

You could do it either way, I suppose, but as I understand "updates" it
places an annotation on RFC6376 indicating that one really needs to read
this document after that one to fully read the state-of-the-art.  If that's
correct, then expressing a delta to the original spec is adequate to
achieve the goal rather than including an entire section of text with only
a few numbers adjusted.

Put simply, you can do either, but the more verbose approach seems like
overkill.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 Aug 2017 18:19:48 -0700

> not render them syntactically invalid.

Another way to look at this: I think it's more appropriate to render
rsa-sha1 obsolete, but this approach seems as if we want to act like it
never existed.

-MSK

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Aug 2017 12:37:13 +1000

One problem I have with the current text is that it buries the lede.
It doesn't outright say what it is doing (worse because I tried to
skip the parenthetical in the paragraph that says this and it never
closes.  Then you have to sift through pages of RFC 6376 that are
largely unchanged.

It's a simple statement.  The document to make that statement should
easily fit on one page (plus one for header boilerplate, plus one for
references and back matter).

On 14 August 2017 at 11:19, Murray S. Kucherawy <[email-masked]> wrote:
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Aug 2017 18:14:01 -0400

> rsa-sha1 obsolete, but this approach seems as if we want to act like it

Fast forward a few years:  Is the fact that it ever existed relevant to 
anything?  I think it's highly unlikely.  

Since RFCs are forever, it'll never be like it never existed (people can 
always read old RFCs if they care), it'll just be like it's irrelevant to the 
current protocol definition.  I think that's appropriate.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2017 01:33:33 -0000

>anything?  I think it's highly unlikely.  

The Internet being the Internet, sha-1 hashes will trickle in forever.
I'd rather have the diagnostic say "obsolete hash" than "syntax
error."

If you look at this curdle draft that deprecates RC4, it goes through
and makes changes to turn OPTIONAL to MUST NOT and the like, but it
doesn't try to undefine the obsolete rc4 crypto modes.  I think you'll
find that typical in crypto updates.

https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Aug 2017 23:26:38 -0400

> https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/

OK.  It seems odd to me, but if that's the IETF norm, no problem.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 16 Aug 2017 14:05:47 -0400

> find that typical in crypto updates.

+1.  The odds are very good that it will continue to be a "will not 
sign, but will verify as needed" behavior for a very long time.  And 
probably, local rules will apply on a site by site basis using other 
bits in the mail.   I am not about to break communications with my 
existing customers or break communications for my installation base.

My key concern here is that the IETF guidelines should not change 
history for future developers. It should help developers as it will be 
a big surprise when SHA1 mail is encountered and these new developers 
are not ready for it.  The 20/20 hindsight question will be raised:

     "Why wasn't it documented that DKIM mail with SHA1 will exist and
      developers should be prepared to deal with it?"

Having the IETF suggest that sha1 DKIM mail MUST|SHOULD be rejected 
with a 55z policy code, is probably not good advice -- IMO.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 19 Aug 2017 15:46:39 -0400

On Saturday, August 12, 2017 09:58:30 PM Salz, Rich wrote:
>     The IETF WG state of draft-ietf-dcrup-dkim-usage has been changed to "In
> WG Last Call" from "WG Document" by Rich Salz:
> 

We're within a few hours of the week being up and the rate of additional 
commentary has fallen to nil, so I took a crack at updating based on the last 
call comments.  I'm attaching an rfcdiff of what I would propose as a post-LC 
-04, but won't upload it until I get some direction.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 20 Aug 2017 17:47:09 -0000

>-04, but won't upload it until I get some direction.

Looks fine to me.  I don't know whether the IANA change should move
SHA-1 to "obsolete" or "historic", but IANA can presumably give advice
about what the practice has been.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 20 Aug 2017 18:00:18 +0000

>about what the practice has been.

Thanks. I'm not sure either, so I left it alone.  Since we aren't removing it from the protocol definition anymore, I think obsolete works with MUST NOT/MUST NOT better than historic, but whatever IANA suggests, as you said.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 20 Aug 2017 22:08:22 -0700

On Sat, Aug 19, 2017 at 12:46 PM, Scott Kitterman <[email-masked]>
wrote:

> > On 8/12/17, 5:55 PM, "IETF Secretariat" <[email-masked]
> >
> > wrote:
> >
> >

Hard to tell since the colors showing what's changed aren't rendering for
me, but it looks like it's going in the right direction.

Only a couple of minor things with this version:

- Section 4.1 gives no guidance to verifiers about what to do with smaller
keys.  It only says it should be able to verify signatures generated with
>= 1024-bit keys.  Do we want to say SHOULD NOT accept smaller keys?
Otherwise, I can accept a 512-bit key and be compliant.  I realize it also
says the thing about local policy, so we're covered as-is, but I'm
surprised we're not sending a stronger message on this point like we did
everything else.

- Section 6 shouldn't change the Reference column for rsa-sha1 since the
place it's actually defined isn't changing.  We're only changing the Status
column of that entry. As for John's question about what the value should
be, Section 7 of RFC6376 stipulates that it has to be either "active" or
"historic", so that's our answer there.

Late last week I met with Seth, who's getting his process feet wet by
shepherding this one, and we went through the process.  He should be
submitting his writeup and/or contacting Scott either offline or via the
list to mention anything outstanding.  Once he submits his final writeup we
can send it along to Alexey.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Aug 2017 10:50:09 -0400

On Sunday, August 20, 2017 10:08:22 PM Murray S. Kucherawy wrote:
> > > At the IETF meeting last month there was strong consensus to have MUST
> > 
> > NOT
> > 
> > >     The IETF WG state of draft-ietf-dcrup-dkim-usage has been changed to
> > 
> > "In
> > 

Thanks.

Updated again.  Revised diff from -03 attached.  I'll upload this soonish 
unless someone else has any more feedback.

Scott K