Subject: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Jun 2017 09:12:16 -0700

Colleagues,

The IETF process doesn't require that working group documents be shepherded
by the chairs.  In an effort to increase the pool of people skilled at our
processes, we started encouraging the use of non-chair shepherds even
before the merged ART area was formed.  I'd like to do that here too.

It's been suggested that draft-ietf-dcrup-dkim-usage is ready for Working
Group Last Call, but before we pull that trigger, I'd like to ask: Is
anyone here interested in acting as document shepherd for this or any other
DCRUP document?  The chairs will happily help you through the process.

-MSK, DCRUP co-chair

---

From: Seth Blank <[email-masked]>
Date: Fri, 9 Jun 2017 09:57:20 -0700

I'm happy to volunteer to shepherd this document.

On Fri, Jun 9, 2017 at 9:12 AM, Murray S. Kucherawy <[email-masked]>
wrote:

> Colleagues,
>
> The IETF process doesn't require that working group documents be
> shepherded by the chairs.  In an effort to increase the pool of people
> skilled at our processes, we started encouraging the use of non-chair
> shepherds even before the merged ART area was formed.  I'd like to do that
> here too.
>
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>
>

-- 

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols
[email-masked]
+1-415-894-2724 <415-894-2724>

---

From: "John Levine" <[email-masked]>
Date: 10 Jun 2017 00:25:38 -0000

In article <[email-masked]> you write:
>Group Last Call, ...

Given that we are nowhere close to deciding what elliptic algorithm(s)
to add, it seems kind of premature to me.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Jun 2017 02:14:29 +0000

On June 9, 2017 8:25:38 PM EDT, John Levine <[email-masked]> wrote:
>In article
><[email-masked]>
>you write:

Why would that matter?  This draft just gets rid of the obsolete cruft.  It clears the deck for adding a new algorithm, but in no way requires we have that sorted out.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 10 Jun 2017 03:04:00 -0000

In article <[email-masked]> you write:
>Why would that matter?  This draft just gets rid of the obsolete cruft.  It clears the deck for adding a new
>algorithm, but in no way requires we have that sorted out.

I had the perhaps overoptimistic hope that we could wrap up the new
algorithm reasonably quickly and update DKIM once rather than twice.

There is a significant cost to each RFC, both in what it costs to
produce it, and to people's attention in the future.  The more places
you spread around the spec, the more likely it is that people will
miss part of it.

If it's going to take us another year to decide which elliptic curve
to use and whether to add key hashes, then OK, we can push this out
now, but I hope we can do better than that.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Jun 2017 03:39:05 +0000

On June 9, 2017 11:04:00 PM EDT, John Levine <[email-masked]> wrote:
>>Why would that matter?  This draft just gets rid of the obsolete
>cruft.  It clears the deck for adding a new

I think it will take awhile.  This particular discussion is the one I thought we'd already had when the group agreed to split this out into a separate draft.

This particular draft is already roughly five years late.

If we don't get something that rips out the obsolete crypto soon, then ARC is either going to have to wait or have a separate crypto specification from DKIM.  I don't see a new protocol with rsa-sha1 512 bits getting approved.  Neither of those options is good.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 10 Jun 2017 12:53:00 -0000

>This particular draft is already roughly five years late.

Sure.  So's mine.

>If we don't get something that rips out the obsolete crypto soon, then ARC is either going to have to wait or have a
>separate crypto specification from DKIM.  I don't see a new protocol with rsa-sha1 512 bits getting approved. 
>Neither of those options is good.

The whole point of spinning up this group was to fix the DKIM crypto
before ARC is published.  Since RSA with more than 1K keys has the
same TXT record problem with ARC as for DKIM, I think it's at least as
urgent to add a future-resistant algorithm with smaller keys as to
deprecate old stuff, probably more so.

This shouldn't be hard, we're not trying to invent anything.  I was
hoping Scott and others who know more about crypto than I do would be
making concrete suggestions about which elliptical algorithm to add,
by now.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 10 Jun 2017 09:42:25 -0400

> If we don't get something that rips out the obsolete crypto soon, then 
> ARC is either going to have to wait or have a separate crypto 
> specification from DKIM.  I don't see a new protocol with rsa-sha1 512 
> bits getting approved.  Neither of those options is good.

I'm not clear on what sequence you're expecting here.  Is this it?

* Update DKIM to take out old crypto

* Publish ARC with only sha256 and RSA1024.

* Update DKIM to add new algorithm and maybe key hashes

* What about ARC?

I'm seeing at least four documents where we should only need two, one to 
update DKIM, one to publish ARC with the same crypto.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Jun 2017 17:44:34 +0000

>update DKIM, one to publish ARC with the same crypto.

Ideally, ARC will be able to use DKIM's crypto requirements by reference and not need its own separate definition.  If ARC can do that, then it doesn't need to be modified once this WG completes.

Today's DKIM crypto requirements are completely unsuitable and would (I hope) never get IETF consensus for a new protocol.  Getting from "unsuitable" to "suitable for today, but not future proofed" is easy.  That's what my draft does.  It's the minimal change needed to avoid ARC having to specify its own crypto requirements, which is what prompted, finally, this working group.

Eventually the working group lands another document that defines the post rsa-sha256 future as an update to DKIM.  Since ARC will incorporate the DKIM crypto requirements by reference, it won't need updating again.

So I see two documents from this WG:

 - one now to get DKIM crypto requirements to be minimally acceptable for today's use
- another to define requirements to be secure in the future so that someday, when it's no longer appropriate, rsa-sha256 can be replaced

Alternately, as you suggest, we land one document that does both.  I thought we made that decision when we adopted this document, so I don't know why we're having the conversation again now.  If we were going to land only one, then we don't need this document at all.

I think you are substantially underestimating the time it will take to get IETF consensus on a new approach based on ECC.  I think if it's done in a year, that'll be fast.

I think I'm done on this particular topic.  

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 10 Jun 2017 18:29:32 +0000

Speaking as an individual and co-chair for CURDLE, not this group...

> This shouldn't be hard, we're not trying to invent anything.  I was hoping
> Scott and others who know more about crypto than I do would be making
> concrete suggestions about which elliptical algorithm to add, by now.

If there is any reason why DKIM cannot use the signature methods just-defined by CURDLE for CMS https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2017 14:43:02 -0400

> If there is any reason why DKIM cannot use the signature methods 
> just-defined by CURDLE for CMS 
> https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/

As far as I know, that would probably work, although DKIM has no CMS or 
ASN.1, just bare base64 keys and signatures.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 10 Jun 2017 19:31:59 -0000

In article <[email-masked]> you write:
>Alternately, as you suggest, we land one document that does both.  I thought we made that decision when we adopted
>this document, so I don't know why we're having the conversation again now.  If we were going to land only one, then
>we don't need this document at all.

I thought the plan was one update doc that will combine the relevant bits.

>I think you are substantially underestimating the time it will take to get IETF consensus on a new approach based on
>ECC.  I think if it's done in a year, that'll be fast.

I sure hope you're wrong.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 10 Jun 2017 19:45:09 +0000

> >I think you are substantially underestimating the time it will take to
> >get IETF consensus on a new approach based on ECC.  I think if it's done in a
> year, that'll be fast.
> 

CFRG already spent all the time working to get consensus on algorithms.  We should be able to have a WGLC-ready document in a couple of months, if we can get a direction and writer(s) by Prague.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Jun 2017 15:59:16 -0400

On Saturday, June 10, 2017 07:45:09 PM Salz, Rich wrote:
> > >get IETF consensus on a new approach based on ECC.  I think if it's done
> > >in a> 
> > year, that'll be fast.
> > 
> CFRG already spent all the time working to get consensus on algorithms.  We
> should be able to have a WGLC-ready document in a couple of months, if we
> can get a direction and writer(s) by Prague.

Given that (which I wasn't aware of), I'll revise my estimate downwards.  I 
still think a separate draft for clearing out the obsolete cruft is worth 
advancing and getting done.

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 10 Jun 2017 20:02:46 +0000

> advancing and getting done.

Yes, there's a growing tradition for "die-die-die" documents.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Jun 2017 16:29:23 -0400

> Yes, there's a growing tradition for "die-die-die" documents.

OK.  Given that, I'd like to resolve the question of how to refer to rsa-sha1 
in section three.  There, as far as I can tell, two visions, roughly what's in 
-02 and what was in -01:

Current (-02):

> 3.  DKIM Signing and Verification Algorithms
> 
>    This section replaces [RFC6376] Section 3.3 in its entirety.
>    
>    Generally, DKIM supports multiple digital signature algorithms.  One
>    algorithm, rsa-sha256, is currenlty defined.  Signers MUST implement
>    and sign using rsa-sha256.  Verifiers MUST implement rsa-sha256.
> 
> 3.1.  The rsa-sha256 Signing Algorithm
> 
>    The rsa-sha256 Signing Algorithm computes a message hash as described
>    in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the
>    hash-alg.  That hash is then signed by the Signer using the RSA
>    algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg
>    and the Signer's private key.  The hash MUST NOT be truncated or
>    converted into any form other than the native binary form before
>    being signed.  The signing algorithm SHOULD use a public exponent of
>    65537.
> 
> 3.2.  Key Sizes
...

and -01:

> 3.  DKIM Signing and Verification Algorithms
> 
>    This section replaces [RFC6376] Section 3.3 in its entirety.
>    
>    DKIM supports multiple digital signature algorithms.  Two algorithms
>    were defined by [RFC6376]: rsa-sha1 and rsa-sha256.  Signers MUST
>    implement and sign using rsa-sha256.  Verifiers MUST implement rsa-
>    sha256.  The rsa-sha1 signing algorithm is obsolete and MUST NOT be
>    used.
> 
> 3.1.  The rsa-sha1 Signing Algorithm
> 
>    This algorithm is obsolete and MUST NOT be used.
> 
> 3.2.  The rsa-sha256 Signing Algorithm
> 
>    The rsa-sha256 Signing Algorithm computes a message hash as described
>    in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the
>    hash-alg.  That hash is then signed by the Signer using the RSA
>    algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg
>    and the Signer's private key.  The hash MUST NOT be truncated or
>    converted into any form other than the native binary form before
>    being signed.  The signing algorithm SHOULD use a public exponent of
>    65537.
> 
> 3.3.  Key Sizes
...

Personally, I prefer the explicit MUST NOT we had in -01 and I think that's 
along the lines of what Martin Thomson was suggesting.  A hatless msk 
preferred something more like what's there now.

Technically, I think the amount to the same thing.  Is it better to be more 
explicit about what's being removed or be implicit by removing it from what's 
specified?  Personally, I think explicit is better than implicit, but being a 
Python guy, I would [1]

Scott K

[1] https://www.python.org/dev/peps/pep-0020/

---

From: Kurt Andersen <[email-masked]>
Date: Sun, 11 Jun 2017 19:17:55 +0100

On Sat, Jun 10, 2017 at 3:14 AM, Scott Kitterman <[email-masked]>
wrote:

> . . .it seems kind of premature to me.
>
> Why would that matter?  This draft just gets rid of the obsolete cruft.
> It clears the deck for adding a new algorithm, but in no way requires we
> have that sorted out.
>

While RFCs do have a cost, can the ADs weigh in on the relative benefits of
doing this "sweep the decks clean" first update to be followed by "add more
algorithms" vs. bundling it all together?

I too think that it might be a bit premature to make a last call though I'm
in support of the two-pass approach.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 11 Jun 2017 20:03:30 -0700

I'll reply about the document sequence separately, but on this point:

> specified?  Personally, I think explicit is better than implicit, but

I think the discussion never fully landed, and it may have gotten mixed in
with the discussion about how to regulate key sizes, if it's even possible
to do that.  Only a few opinions have been expressed, and nobody's
commented up or down on the -02 text yet.

Remaining hatless, I prefer the current approach because, like key sizes,
we're not talking about an interoperability concern but rather a policy
one.  There's nothing broken about DKIM implementations that use rsa-sha1.
It's just a bad idea now although it wasn't yet when RFC4871 came out.
Although many receivers may choose to treat all rsa-sha1 signatures as
failed on principle, that's not (and, I would argue, shouldn't be)
intrinsic in the protocol.

My understanding of the use of RFC2119 language is that it's used to
describe choices that affect interoperability, while small key sizes and
use of SHA1 are choices that clearly reduce security but interoperate just
fine.  Then Martin suggested that there's precedent in other RFCs for using
RFC2119 language to discourage use of obsolete security mechanisms.  If
that's the case and we're fine with it, then I'll go along with consensus.

That aside, simply not describing rsa-sha1 going forward, and including an
IANA action to mark it "deprecated" in the registry, seems right to me.  If
we want to add a paragraph in an appendix paying homage to it and including
advice about why its use is no longer a good idea, that's fine too.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 11 Jun 2017 20:37:23 -0700

On Sun, Jun 11, 2017 at 11:17 AM, Kurt Andersen <[email-masked]> wrote:

> While RFCs do have a cost, can the ADs weigh in on the relative benefits
> of doing this "sweep the decks clean" first update to be followed by "add
> more algorithms" vs. bundling it all together?
>

Regardless of the answer to that, I don't think we should be in some sort
of hurry here.

>From where I'm sitting, ARC has other questions it needs to work out before
this will be a pressing issue for them, and for the most part they just say
"do what DKIM does" in terms of key management anyway, so when we change
DKIM, ARC will just follow.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Jun 2017 00:38:28 -0400

> DKIM, ARC will just follow.

The IETF is five years late with action on this front.  At least.  Whatever is 
happening in this working group, hurrying isn't on the list.

I have no idea what should be in this draft or if it should even exist 
anymore.

I also really don't understand why we have a discussion about if a draft 
should be adopted before a WG adopts it if we just get to re-have the same 
discussion periodically.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Jun 2017 00:23:16 -0700

> happening in this working group, hurrying isn't on the list.

Then I don't understand why this thread seems to be so tense with
frustration.

> anymore.

I really don't think the proposed changes are all that major here.

> should be adopted before a WG adopts it if we just get to re-have the same

You think working groups should not be allowed to revisit their choices?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2017 23:08:02 -0000

>advice about why its use is no longer a good idea, that's fine too.

That's what I'd suggest.  The spec should say what to do if you want to
interoperate.  It needn't call out things not to do in the spec -- there's an
unlimited number of them.  If you want to put an appendix explaining why
the current things to do have changed, that's OK but not urgent.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Jun 2017 10:29:07 -0400

> Then I don't understand why this thread seems to be so tense with

I think getting rid of sha1 and keys < 1024 bits should be really easy.  

I THOUGHT we had all agreed to get that done and out of the way.  In the space 
of two days we went from "OK, almost done" to "Here's three different visions 
for how the draft should be written that all say the same thing" or maybe 
don't bother.  That's frustrating.

I find the notion that it's not an interoperability problem for signers to 
sign with keys that receivers will ignore frustrating.

> I really don't think the proposed changes are all that major here.

If I knew which of the three approaches to take, then I could  pick one and 
write it:

1.  Fully replace section 3.3 explicitly saying MUST rsa-sha256 and MUST NOT 
rsa-sha1 (my personal preference)

2.  Fully replace section 3.3 dropping rsa-sha1 and just giving the new 
requirements (possibly with an appendix that says MUST NOT rsa-sha1)

3.  Make the draft a lot shorter and only state updated requirements.  Also 
don't remove rsa-sha1 [1]

As a maintainer of an implementation of RFC 4871 and its updates (e.g. RFC 
6376) and its updates, I strongly prefer option #1.  That structure makes it 
very easy to see what needs changing when I update the code.  

Using the approach in option 2 I need to either mentally diff RFC 6376 and the 
new document (or if we add it look at the main body of the text and an 
appendix) to determine what to do.  It's less clear.

Option 3 makes the entire document a no-op.  It both fails to remove rsa-sha1 
and offers no guidance on key sizes.  The one new thing it says (compared to 
RFC 6376 is "Verifiers MUST NOT rely on the rsa-sha1 algorithm".  What does 
that even mean?  Since rsa-sha1 is not removed from the ABNF, it's still a 
required part of the protocol.  Once we add an ECC algorithm are all three 
going to be required?

I would like to know what the group prefers.  I'll do whatever, but I really 
have no idea what that is.  If option 4 is kill the document, my ranking would 
be:

1
2
4
3

> You think working groups should not be allowed to revisit their choices?

You think working groups should have a bi-weekly periodic on revisiting 
choices?  Of course choices can be revisited, but if decisions aren't at all 
sticky, then there's no way to make progress.

Scott K

[1] https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1/commits/b7815a3b876c5b57f7eff4537ed0c0e9eef497a8

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Jun 2017 13:57:30 -0700

On Mon, Jun 12, 2017 at 7:29 AM, Scott Kitterman <[email-masked]>
wrote:

> choices?

<chair, though having not talked to my co-chair about this yet>

We haven't been chartered long enough for that hyperbole to have any
basis.  I believe this is only the first time such a change has been
proposed.  If this is going to be the discussion any time someone hints at
revisiting a choice we've made about a document, this working group is
going to take a really long time to finish.

Of course choices can be revisited, but if decisions aren't at all
> sticky, then there's no way to make progress.

To be sure, once consensus is reached on something, anyone who wants to
change it has the burden to justify the change by doing the work to shift
consensus.  As a bonus, the weight of that burden generally gets heavier
the more time passes.

But that's as "sticky" as it gets.  The conversation is allowed to happen,
and attempts to stifle it are not appropriate.

</chair>

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Jun 2017 17:27:37 -0400

On Monday, June 12, 2017 01:57:30 PM Murray S. Kucherawy wrote:
> > > > I also really don't understand why we have a discussion about if a
> > 
> > draft
> > 
> > > > should be adopted before a WG adopts it if we just get to re-have the
> > 
> > same
> > 
> > > > discussion periodically.
> > > 

OK.  Fair enough.

I know I get grumpy sometimes.  I also get over it.

Moving on ...

Scott K

---

From: Seth Blank <[email-masked]>
Date: Tue, 13 Jun 2017 08:49:48 +0100

> don't remove rsa-sha1 [1]

I think #2 is the cleanest for a lot of reasons, but I'm sympathetic to the
argument about the RFC making it clear what has changed to an implementer
reading it and this has persuaded me, If the point of this document is to
get implementers who have been using sha-1 and weak keys to throw them out
- #1's language accomplishes this explicitly.

So I'm voting for #1.

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 13 Jun 2017 10:53:21 +0100

On Tue, Jun 13, 2017 at 8:49 AM, Seth Blank <[email-masked]> wrote:

> I think #2 is the cleanest for a lot of reasons, but I'm sympathetic to
> the argument about the RFC making it clear what has changed to an
> implementer reading it and this has persuaded me, If the point of this
> document is to get implementers who have been using sha-1 and weak keys to
> throw them out - #1's language accomplishes this explicitly.
>
> So I'm voting for #1.
>

I'd much prefer approach #2, but rather than "replace in place", the
replacement should point to a registry with the details in the registry
subject to expert review for future updates. The initial population of
registry entries should designate sha1 and rsa keys <1024bits as either
"not supported" or "deprecated" or whatever other terminology conveys the
same message in registry-speak.

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 13 Jun 2017 00:21:17 -0000

>same message in registry-speak.

Take a look at my draft.  There already is a registry for hash
algorithms, and mine moves sha1 to historic.  

There's no registry for key sizes, and creating one would be tough.
For RSA, you can create a key with as many bits as you want.  You want
a 1775 bit key, you can use a 1775 bit key.  I'd rather keep the
advice about key size in the text since the alternative would seem to
be to list every key size from 512 to whatever and mark them
individually good or bad.

For the elliptic algorithms, there's no choice of key size so nothing
to put in a registry.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Jun 2017 06:13:23 -0700

> same message in registry-speak.

We have such a registry, here:

https://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml

Look for "DKIM Hash Algorithms".  We just need to mark "sha1" as
"deprecated" or some such.

This doesn't cover key sizes, but that was discussed elsewhere.  I still
don't think that belongs in a registry as a bare parameter.

-MSK