Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt

From: [email-masked]
Date: Wed, 07 Jun 2017 22:47:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DKIM Crypto Update of the IETF.

        Title           : Cryptographic Algorithm and Key Usage Update to DKIM
        Author          : Scott Kitterman
	Filename        : draft-ietf-dcrup-dkim-usage-02.txt
	Pages           : 6
	Date            : 2017-06-07

Abstract:
   The cryptographic algorithm and key size requirements included when
   DKIM was designed in the last decade are functionally obsolete and in
   need of immediate revision.  This document updates DKIM requirements
   to those minimaly suitable for operation with currently specified
   algorithms.  This document updates RFC 6376.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dcrup-dkim-usage-02
https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-usage-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 08 Jun 2017 01:50:13 -0400

On Wednesday, June 07, 2017 10:47:13 PM [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the DKIM Crypto Update of the
> IETF.
> 
>         Title           : Cryptographic Algorithm and Key Usage Update to
> DKIM Author          : Scott Kitterman

There are only a few small changes in this revision.  I applied the diff I 
posted in response to msk's suggestion about saying even less about rsa-sha1 
and I filled out the acknowledgements with everyone who's commented about the 
draft (if I missed you or you'd rather not be listed, please let me know).

Please give this revision a good review and based on the feedback to date, I 
think it's pretty close to done.

Scott K

---

From: Russ Housley <[email-masked]>
Date: Fri, 9 Jun 2017 16:13:28 -0400

> On Jun 8, 2017, at 1:50 AM, Scott Kitterman <[email-masked]> wrote:
> 

I think the document is ready for WG Last Call.

Russ

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 9 Jun 2017 14:18:56 -0700

> I think the document is ready for WG Last Call.

I agree.

fwiw: The only typo I see remaining is at the end of Section 6 Security
Considerations 'from DKIM..' uses two period characters rather than just
one.

	-- Mark

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Jun 2017 02:30:44 -0400

> Considerations 'from DKIM..' uses two period characters rather than just

Thanks.  Fixed locally for the next revision.

Scott K

---

From: Martin Thomson <[email-masked]>
Date: Sat, 10 Jun 2017 10:42:34 +0100

I find the construction of this draft strange.  Why not simply say
"verifiers MUST implement and use rsa-sha256 instead of rsa-sha1"?
The remainder of the text is largely unchanged, which took me a while
to validate.

The problem here is that removing the definition of rsa-sha1 is not
the point.  The code point can't be undefined (Section 7 gets that
right), and we don't really benefit from having the definition
removed.  What we want is to have rsa-sha256 implemented and deployed.

So say two things, just to be perfectly clear:

1. DKIM implementations MUST NOT rely on rsa-sha1, it's busted.

2. DKIM implementations MUST use rsa-sha256.  Signers MUST create
signatures using rsa-sha256 and verifiers MUST verify those
signatures.

I disagree with John about the publication of this draft without the
new schemes.  It's worth doing now and the extra overheads of
publication are small.

Nits:

Section 3, two errors here:

> One algorithms, rsa-sha256, is currenlty defined.

Section 3.2 s/,/ / here:

> DKIM,[RFC6376]

Section 6 has an extra period.

Collapse Section 7.1 into Section 7:

"""
IANA is requested to update the "sha1" registration in the "DKIM Hash
Algorithms" as follows:
<table>
"""

On 8 June 2017 at 06:47,  <[email-masked]> wrote:
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Jun 2017 14:33:54 -0400

> signatures using rsa-sha256 and verifiers MUST verify those

This is pretty much what we had in -01 and this approach was suggested 
instead.  In XML, sorry, here's the diff:

https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/commit/b3956a026c18b88ac2f47f8a012610598149e286

I liked it better before, which is more like I believe you are suggesting, so 
let's see what others say on that particular topic.

> new schemes.  It's worth doing now and the extra overheads of

Exactly.

> > One algorithms, rsa-sha256, is currenlty defined.

Done.

> > DKIM,[RFC6376]

Done.

> Section 6 has an extra period.

Fixed.

> IANA is requested to update the "sha1" registration in the "DKIM Hash

Done.

snip.

Scott K

---

From: Martin Thomson <[email-masked]>
Date: Sun, 11 Jun 2017 09:40:00 +0100

> https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/commit/b3956a026c18b88ac2f47f8a012610598149e286

That's not quite what I was suggesting. I have sent you a PR for what
I think you should say:

https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1

I think that I got the essence of your changes there.  And it's a lot shorter.

Another issue I encountered when doing this:

         The defining documents specify a single signing algorithm,
<xref target="RFC8017">RSA</xref>
,
        and recommends key sizes of 1024 to 2048 bits (but require
verification of 512 bit keys).
        As discussed in <xref target="VULNOTE">US-CERT
VU#268267</xref>, the operational
        community has recognized that shorter keys compromise the
effectiveness of DKIM.
        While 1024 bit signatures are common, stronger signatures are
not.  Widely used DNS
        configuration software places a practical limit on key sizes,
because the software only
        handles a single 256 octet string in a TXT record, and RSA
keys longer than 1024 bits don't
        fit in 256 octets.

Aside from the extra space after the first xref, there are two
problems with this paragraph.

First, this document doesn't change anything about the recommendations
regarding key sizes.  That makes the whole paragraph a little
misleading.  You give the impression that you are doing something
about key sizes, but then you don't.

Second, you can fit a key larger than 1024 bits in less than 256
octets.  A 1536-bit key isn't that great, but it's a huge amount
better than 1024.  I haven't done the math, but I'm sure that you
could find a number that maximizes key length without blowing the 256
octet limit.  This might be good advice to add (which would also mean
that you can keep the paragraph).

---

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

> I think that I got the essence of your changes there.  And it's a lot

Can you explain what you mean by "rely on"?

> that you can keep the paragraph).

Interesting.  And there's a bit of a variability since the key record can
have other stuff in it (3.6.1 of RFC6376) which reduces the amount of space
available for the "p=" value.

My possibly ignorant run at the math:
- my 1024-bit public key encodes to base64 in 217 characters
- there are 255 octets available in a character-string in a TXT record
- subtracting 10 from that for "v=DKIM1;p=" which are required, leaves 245
assuming there's no other cruft or spaces in the record
- for 217:1024 = 245:x, x=1156

So by that logic, you can put a 1156-bit key in a record now without
changing anything.  For anything bigger you will need multiple
character-strings in the TXT field which I believe is one of the things
John says doesn't fly in current provisioning software.

-MSK

---

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

> signatures using rsa-sha256 and verifiers MUST verify those

That idea is fine with me.  Specifically, I think "MUST NOT rely on" is
better than "MUST NOT implement".

-MSK

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Jun 2017 08:20:18 +0100

> Can you explain what you mean by "rely on"?

Sure, that's probably a bit of an imprecise way of saying that a
verifier needs to insist on receiving a valid rsa-sha256 signature and
that it can't just fall back to rsa-sha1.

> character-strings in the TXT field which I believe is one of the things John
> says doesn't fly in current provisioning software.

1156 is better, but I was hoping for a bit higher than that.  I would
include text that suggests this (explaining the limitations you set
out regarding the whitespace and so forth), but note that the
additional security margin is, well, marginal.

---

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

>additional security margin is, well, marginal.

Of course it is.  My draft has two approaches to stronger crypto in
256 bytes of TXT.  One is key hashes with the key in the signature,
the other is elliptic crypto.

At this point it seems likely that we'll do the elliptic crypto so I'm
inclined to skip the key hashes.

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Jun 2017 10:26:53 +0100

> inclined to skip the key hashes.

This is an odd angle to take here.

Key hashes would remove the limit entirely.  I appreciate that you
think that 1024-1156 is of marginal benefit, but the benefit of key
hashes is that you can use the existing, certified, and tested
primitives AND keys that you have already.  It's a much smaller
increment.  That makes me inclined to think that hashed-RSA has some
value.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Jun 2017 10:30:00 +0100

Yes, I think we should do hashed-<everything>, for obvious reasons.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 12 Jun 2017 10:45:02 +0100

> increment.  That makes me inclined to think that hashed-RSA has some

If the RFC 8032 algorithm isn't existing, certified, and tested, we've got 
problems beyond DCRUP.  Hashes in principle are simple, but they got taken 
out in 2006 because of complaints about bulking up the signature with the 
key, and we can bikeshed forever on which hash to use and how to represent 
it.  If people are going to make one change to update their DKIM signers 
and verifiers, I'd rather they add a protocol switch to add better crypto.

Also remember that 2K RSA signatures work fine in DKIM.  The problem is 
cruddy DNS provisioning software that won't publish multi-string TXT 
records.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Jun 2017 10:49:38 +0100

On 12 June 2017 at 10:45, John R Levine <[email-masked]> wrote:
> problems beyond DCRUP.

That wasn't my point.  It was that deploying something based on RSA is
potentially more attractive.  That's a trend I've witnessed.  Cautious
management/developers/operations will avoid the new thing for a range
of reasons.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Jun 2017 10:49:25 +0100

On Mon, Jun 12, 2017 at 10:45 AM, John R Levine <[email-masked]> wrote:

> it.

You can bikeshed on anything, but I don't see how this is actually a
particular problem,
given that you can pin the hash to the signature algorithm, as we do with
elliptic curves.

TBH, I'm not sure why we're debating this point, given that hashes are
actually in the
charter:

"DCRUP will consider three types of changes to DKIM: additional signing
algorithms such as those based on elliptic curves, changes to key
strength advice and requirements, and new public key forms, such as
putting the public key in the signature and a hash of the key in the
DNS to bypass bugs in DNS provisioning software that prevent publishing
longer keys as DNS TXT records."

  If people are going to make one change to update their DKIM signers and
> verifiers, I'd rather they add a protocol switch to add better crypto.
>

Yeah, the issue here is that hashes set us up for the future.

-Ekr

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Jun 2017 08:15:10 -0400

> inclined to skip the key hashes.

​Key hashes may be of use when we come to do quantum safe algorithms.

Though it might well be that given the vulnerabilities DCRUP is ultimately
addressing, non QCR algorithms will remain satisfactory.​

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jun 2017 14:12:07 +0000

> At this point it seems likely that we'll do the elliptic crypto so I'm inclined to
> skip the key hashes.

Speaking purely as an individual, I am in favor of this.  We used to think things would go 1KRSA 2KRSA 4KRSA, but people are moving to ECC instead of 4KRSA.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jun 2017 14:18:50 +0000

> Speaking purely as an individual, I am in favor of this.  We used to think things
> would go 1KRSA 2KRSA 4KRSA, but people are moving to ECC instead of
> 4KRSA.

I also, as an individual, prefer things to be as self-contained as possible.

---

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

> that it can't just fall back to rsa-sha1.

The way to do that would be to remove it from the protocol, which you seem to 
oppose, so I'm confused.

> additional security margin is, well, marginal.

1024 is operationally very common.  In the end, if it matters, I don't mind 
adding this discussion, but I also don't see any reason to set the floor 
higher than 1024 (I don't think there's enough security advantage in 1156 over 
1024 to matter).

Scott K

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Jun 2017 15:41:01 +0100

> The way to do that would be to remove it from the protocol, which you seem to

I don't oppose removing it from the protocol in practice, it's just
that you can't pretend that the old version doesn't exist, and nor
should you care.  The point is to not USE it, the definition becomes
harmless at that point.

> higher than 1024 (I don't think there's enough security advantage in 1156 over

This I agree with.

The reason I suggested this is that your current draft doesn't
*actually* include any new advice about key sizes.  1156 would be
advice you could give, but as I said, that's of marginal benefit.

---

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

On Monday, June 12, 2017 03:41:01 PM Martin Thomson wrote:
> > The way to do that would be to remove it from the protocol, which you seem
> > to oppose, so I'm confused.
> 

I disagree on that point, but I guess we'll see what others think.  I think as 
long as it's in the protocol, it's problematic.

> > higher than 1024 (I don't think there's enough security advantage in 1156
> > over 1024 to matter).
> 
> This I agree with.
> 

Yes.  It's focused on trying to define a secure/interoperable set of 
requirements that are common between senders and receivers.  I didn't see 
anything that really needed updating about the drivers for choices within 
those bounds.

Scott k

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jun 2017 15:05:43 +0000

> *actually* include any new advice about key sizes.

Does it have to in order to be useful?  I don't think so.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 12 Jun 2017 09:52:13 -0700

On 6/11/17 8:28 PM, Murray S. Kucherawy wrote:
> On Sat, Jun 10, 2017 at 2:42 AM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> That idea is fine with me.  Specifically, I think "MUST NOT rely on"
> is better than "MUST NOT implement".

The difference between "rely on" and "implement" is not at all clear to me.

Backing up: For interoperability, ideally we would have some transition
time between when rsa-sha1 is no longer an acceptable signing algorithm
and when it's no longer an acceptable verification algorithm. RFC 6376
didn't quite close the door on use of rsa-sha1 for signing, so it's
premature to say that it's no longer acceptable for verification. Put
another way, if a frequent correspondent of a domain signs with
rsa-sha1, they're going to want to verify those signatures regardless of
what we say here.

Yes, rsa-sha1 is busted, but is it busted in a way that is likely to be
exploited in this application? There are other weaknesses, most notably
spoofing of key records in DNS, that are far more likely to be used;
remember that DKIM tries to discourage other uses for keys (e.g., for
data encryption) for those reasons. Also, factoring of keys and spoofing
of key records are much more scalable than an attack on a particular
message's hash.

Does anyone have any data on how prevalent use of rsa-sha1 is currently
in the field? If nobody is actually using it, I would believe that RFC
6376 closed the door more than I thought.

-Jim

---

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

Hatless:

> should you care.  The point is to not USE it, the definition becomes

+1.

-MSK

---

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

On Monday, June 12, 2017 01:54:57 PM Murray S. Kucherawy wrote:
> > > The way to do that would be to remove it from the protocol, which you
> > > seem to oppose, so I'm confused.
> > 

I've thought about this some more.  And the more I think about it, the less I 
like it.

Here are the currently defined DKIM result names from the IANA Email 
Authentication Result Names registry[1]:

> dkim 	neutral 	[RFC7601] section 2.7.1 	active
> dkim 	none 	[RFC7601] section 2.7.1 	active
> dkim 	pass 	[RFC7601] section 2.7.1 	active
> dkim 	permerror 	[RFC7601] section 2.7.1 	active
> dkim 	policy 	[RFC7601] section 2.7.1 	active
> dkim 	temperror 	[RFC7601] section 2.7.1 	active

What's the proper result for a rsa-sha1 signed message that passes DKIM 
verification?  It's not 'none', because it's still a valid signature.  I hope 
it's not 'pass' since there's no way to communicate it should not be relied 
on.  If we really want to approach it this way, there needs to be a new 
result, something like pass-but-ignore (since downstream consumers will rely 
on a pass).

This seems like a horribly recipe for confused implementation for exactly no 
benefit.  If anyone is sending exclusively rsa-sha1 signed mail (I don't have 
access to a reasonable corpus to have an opinion on the rarity) they're 
ignoring a SHOULD NOT that dates back to the very first DKIM RFC a decade ago.

I would really appreciate it if someone in favor if keeping rsa-sha1 would 
describe, in detail, what the authentication-results header field is supposed 
to look like for this "it's valid DKIM, but don't rely on it" approach.

Scott K

[1] https://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-result-names

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jun 2017 11:50:42 +0100

> Does it have to in order to be useful?  I don't think so.

The introduction implies that there is advice (see the last
paragraph).  There is text on key sizes, but it is copied verbatim
from 6376 as far as I can see, that is why the question arose.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jun 2017 11:52:42 +0100

On 12 June 2017 at 22:39, Scott Kitterman <[email-masked]> wrote:
> verification?

Oh, I see where you are coming from.  I think that you need text that
says "an rsa-sha1 signature MUST be ignored by a verifier".  I think
that answers the questions about "rely on" more clearly.

---

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

> that answers the questions about "rely on" more clearly.

If we really need to say something like this, I'd prefer to drop the
MUSTard for previously given reasons.  Suggest something like:

"Since SHA1 is a deprecated hash algorithm generally, DKIM's 'rsa-sha1'
algorithm is as well (see [John's draft] which changes its status in the
IANA registry), and thus verifiers therefore ignore signatures that use
this algorithm."

-MSK

---

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

> IANA registry), and thus verifiers therefore ignore signatures that use

Uh... we can vote on "thus" or "therefore".  (*shame*)

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Tue, 13 Jun 2017 07:30:42 -0700

On 6/13/17 6:46 AM, Murray S. Kucherawy wrote:
> On Tue, Jun 13, 2017 at 6:32 AM, Murray S. Kucherawy
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     "Since SHA1 is a deprecated hash algorithm generally, DKIM's
>     'rsa-sha1' algorithm is as well (see [John's draft] which changes
>     its status in the IANA registry), and thus verifiers therefore
>     ignore signatures that use this algorithm."
>
>

:)

But "verifiers ignore signatures" doesn't seem like very good normative
language. Are they required to (MUST) or is it a strong (SHOULD) or
weaker (MAY) suggestion?

Since we have seen that there are still a lot of rsa-sha1 signers out
there, encouraging verifiers to ignore those signatures (and
implementers not to provide rsa-sha1 verification), in the absence of
something that is likely to be exploitable, flies in the face of
interoperability. Cutting off verification is a lever that should be
used only after having said that they SHALL not sign with rsa-sha1, and
the current spec doesn't say that.

-Jim

---

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

On Tue, Jun 13, 2017 at 7:30 AM, Jim Fenton <[email-masked]> wrote:

> language. Are they required to (MUST) or is it a strong (SHOULD) or weaker
> (MAY) suggestion?
>

Get Pete Resnick in here!

You don't need any of those things.  "Verifiers ignore SHA1 signatures"
means that's what they do if they comply with this update.  Sticking a MUST
in there doesn't change anything; anyone that wants to comply will, and
anyone who has no idea about any of this won't.

Alternatively, we could load this up with a sentence or two describing why
it's a grand idea to ignore such signatures.

-MSK

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jun 2017 22:41:29 -0400

> given that you can pin the hash to the signature algorithm, as we do with

As a process matter. Could we not use the term 'bikeshed' when
referring to contributions?

I am completely serious about this. I have seen the term used by
certain individuals to essentially trash someone's contribution and
then gaslight them. It really does get used as a form of harassment in
IETF.

Basically what I hear is, 'this is an unimportant issue so we are
going to do it my way and I can't be bothered to enter into
discussions on the topic because your work on the issue is utterly
insignificant'.

Choice of identifiers is an important consideration in any protocol.
In fact it is pretty much the only decision to make most of the time.

Wanting to do a job properly is not 'bikeshedding'.