Subject: [Dcrup] rsa-sha1 proposals

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Jun 2017 11:39:34 -0400

I think we still have some different opinions on what to do with rsa-sha1, so 
I thought I'd attempt to summarize the different options (as best I can, I 
have an opinion, so I'm sure my bias will leak in) in the hopes it will help 
drive this part of the WG discussion to closure.  Note: I'm not talking about 
RSA key sizes because it seems to me we're largely converged on that topic.

I think there are roughly three options that have been discussed:

Status quo:

> Signers MUST implement and SHOULD sign using rsa-sha256.  Verifiers MUST
> implement both rsa-sha1 and rsa-sha256.

Deprecate rsa-sha1:

> Signers MUST implement and sign using rsa-sha256 only.  Verifiers MUST
> implement both rsa-sha1 and rsa-sha256.

Remove rsa-sha1:

> Signers MUST implement and sign using rsa-sha256 only.  Verifiers MUST
> implement rsa-sha256.  rsa-sha1 is obsolete and MUST not be used.
Note: This option also removes rsa-sha1 from the ABNF.

Pro/Con for each:

Status quo:
There is no immediate known security threat to rsa-sha1 that would indicate 
its imminent demise as a useful algorithm in this application and rsa-sha1 
signatures are still in significant use.  RSA key sizes are the current 
security issue and that can be fixed without doing anything about rsa-sha1.

There are a number of known shortcomings with rsa-sha1 and given that rsa-
sha256 is available and does not share the same issues, raising the bar to 
require rsa-sha256 is easy and a prudent step to take in advance of issues 
being published.  Let's not wait until we have to panic.

Retaining rsa-sha1 means DKIM implementers will have to deal with three 
algorithms rather than two and this raises implementation complexity and the 
risk of things going wrong.

Deprecate rsa-sha1:
There is no immediate known security threat to rsa-sha1 that would indicate 
its imminent demise as a useful algorithm in this application and rsa-sha1 
signatures are still in significant use.  RSA key sizes are the current 
security issue and that can be fixed without doing anything about rsa-sha1, 
but if we move to a more aggressive stance against rsa-sha1 now, it should be 
easier to remove it when needed.

There are a number of known shortcomings with rsa-sha1 and given that rsa-
sha256 is available and does not share the same issues, raising the bar to 
require rsa-sha256 is easy and a prudent step to take in advance of issues 
being published.  Let's not wait until we have to panic.

Retaining rsa-sha1 means DKIM implementers will have to deal with three 
algorithms rather than two and this raises implementation complexity and the 
risk of things going wrong.

Remove rsa-sha1:
This option eliminates (to the extent it is adopted) the potential of security 
risks with rsa-sha1.  If a relevant issue with rsa-sha1 is made public, there 
will be no further standards work that needs to be done.  This option also 
keeps the number of algorithms at two, eliminating the additional complexity 
associated with having more algorithms to sort through in implementation.  
While this might be considered somewhat abrupt, rsa-sha1 signing has been 
effectively SHOULD NOT for a decade.  Maybe this will create some momentum for 
operators to move off of it.

It is abrupt to remove something without a formal deprecation period.

Thoughts?

Scott K

---

From: Seth Blank <[email-masked]>
Date: Tue, 20 Jun 2017 09:18:56 -0700

> It is abrupt to remove something without a formal deprecation period.

I strongly vote to remove SHA1 as proposed here; I do not believe any other
approach will incentivize senders or receivers to make the change.

I do not believe this qualifies as an "abrupt" deprecation, as you said, it
has been SHOULD NOT for over a decade.

> Thoughts?
>
> Scott K
>
>
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Jun 2017 12:36:35 -0400

> has been SHOULD NOT for over a decade.

Modulo the IETF doesn't vote, I agree, but then you knew that already.  
Hopefully the responses give enough information for the chairs to develop an 
opinion about where the consensus is on this issue.

Thanks,

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Jun 2017 16:43:09 +0000

I don't think an RFC is ever abrupt deprecation; instances are free to not implement.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 20 Jun 2017 10:52:40 -0700

If it isn't obvious from my previous comments, I favor the "Deprecate
rsa-sha1" option. I might even suggest we soften it to say that
verifiers MUST implement rsa-sha256 and SHOULD implement rsa-sha1; it's
ultimately up to the verifier to decide what signatures they trust and
they might decide not to implement rsa-sha1 if they know they will never
accept one of those signatures anyway.

Having been away from this stuff for a while, I was startled that the
hash algorithms were named directly in the ABNF rather than by reference
to the registry, but that's what we do apparently. The description of
the rsa-sha1 algorithm (3.3.1 in RFC 6376) can be removed as well when
rsa-sha1 is removed entirely, of course.

-Jim

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 20 Jun 2017 12:00:05 -0700

> Note: This option also removes rsa-sha1 from the ABNF.

[elided]

Remove rsa-sha1:
> risks with rsa-sha1.  .  .

I'm in favor of moving strongly and clearly to kill sha1, but what about
moving it out to the registry with a dated "MUST NOT". That provides for a
deprecation period without the need for further intervention. The other
advantage is that it provides a stronger historical record that people can
point to when explaining brain-deadness to people who have not updated :-)
I would suggest a "drop dead" date of something like mid-2018 to allow the
rest of this work to reach completion.

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Tue, 20 Jun 2017 13:11:37 -0700

I think we should go for removal.

I don't think implementation wise for receivers who have a choice, that
removal vs deprecation is going to have a big short-term impact, I doubt
most receivers would remove rsa-sha1 at the publish date or on the
deprecation date in the registry.  They'll assess the damage between
keeping it or removing it based on the current timeframes.

The larger question will be if implementations that others depend on start
removing it, ie if you upgrade your version of opendkim and rsa-sha1 is no
longer supported, you'll likely have unexpected changes to your receiving.
That said, I think that deprecation doesn't change the status quo enough.

Brandon

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Jun 2017 18:47:31 -0400

On 6/20/2017 3:00 PM, Kurt Andersen wrote:
>
> I'm in favor of moving strongly and clearly to kill sha1, but what
> about moving it out to the registry with a dated "MUST NOT". That
> provides for a deprecation period without the need for further
> intervention. The other advantage is that it provides a stronger
> historical record that people can point to when explaining
> brain-deadness to people who have not updated :-)
> I would suggest a "drop dead" date of something like mid-2018 to allow
> the rest of this work to reach completion.
>

-1.

I'm not going to stop supporting SHA1 and invaliding signatures based 
on a drop dead date. I would prefer a "hint" from the already existing 
overhead DNS lookups being down, i.e. either the key lookup or author 
domain policy.   If the "Author Domain" says "we only do SHA256, then 
that should allow for a supportive verifier to act accordingly.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Jun 2017 18:50:19 -0400

I would prefer if a "Author Domain Policy" said what is supported. We 
can add that hint to the DKIM or DMARC lookup that is already being 
done.  We should leverage that overhead lookup. I don't see stopping 
supporting SHA1 (pulling existing code).

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Jun 2017 18:58:13 -0400

You are describing the existing optional h= tag for DKIM records.  Nothing new 
is needed to specify the acceptable algorithm for the key.  

Since there are no Internet police, no one will make you delete your rsa-sha1 
code no matter what we write here.

Scott K

On Tuesday, June 20, 2017 06:50:19 PM Hector Santos wrote:
> > I think we still have some different opinions on what to do with rsa-sha1,
> > so I thought I'd attempt to summarize the different options (as best I
> > can, I have an opinion, so I'm sure my bias will leak in) in the hopes it
> > will help drive this part of the WG discussion to closure.  Note: I'm not
> > talking about RSA key sizes because it seems to me we're largely
> > converged on that topic.
> > 
> > algorithms rather than two and this raises implementation complexity and
> > the risk of things going wrong.
> > 
> > 
> > Deprecate rsa-sha1:
> > but if we move to a more aggressive stance against rsa-sha1 now, it should
> > be easier to remove it when needed.
> > 
> > algorithms rather than two and this raises implementation complexity and
> > the risk of things going wrong.
> > 
> > Remove rsa-sha1:
> > This option eliminates (to the extent it is adopted) the potential of
> > security risks with rsa-sha1.  If a relevant issue with rsa-sha1 is made
> > public, there will be no further standards work that needs to be done. 
> > This option also keeps the number of algorithms at two, eliminating the
> > additional complexity associated with having more algorithms to sort
> > through in implementation. While this might be considered somewhat
> > abrupt, rsa-sha1 signing has been effectively SHOULD NOT for a decade. 
> > Maybe this will create some momentum for operators to move off of it.
> >

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2017 23:06:41 -0000

In article <[email-masked]> you write:
>moving it out to the registry with a dated "MUST NOT".

Back in 2007 RFC 4871 said "In general, sha256 should always be used
whenever possible."  I think people have had enough warning, and if we
want to kill it, we should just kill it.

>The other

Having known too many of those people, a document that says anything less
than "do not use SHA-1 for any reason, ever" will be interpreted as see,
we don't have to change.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Jun 2017 19:14:00 -0400

> code no matter what we write here.

Understood, but it shouldn't be expected signer/verifiers would just 
"turn it off" either in established and legacy setups, small to larger.

It would be helpful, if an automated protocol logic hint was provided. 
  I've been out of the loop for this DCRUP (and ARC), but has "h=" 
update proposal been made? It currently says:

    h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
       allowing all algorithms).  A colon-separated list of hash
       algorithms that might be used.  Unrecognized algorithms MUST be
       ignored.  Refer to Section 3.3 for a discussion of the hash
       algorithms implemented by Signers and Verifiers.  The set of
       algorithms listed in this tag in each record is an operational
       choice made by the Signer.

       ABNF:

       key-h-tag       = %x68 [FWS] "=" [FWS] key-h-tag-alg
                         *( [FWS] ":" [FWS] key-h-tag-alg )
       key-h-tag-alg   = "sha1" / "sha256" / x-key-h-tag-alg
       x-key-h-tag-alg = hyphenated-word   ; for future extension

Maybe the "extension" can be used to automate protocol?

Section 3.3 says:

3.3.  Signing and Verification Algorithms

    DKIM supports multiple digital signature algorithms.  Two algorithms
    are defined by this specification at this time: rsa-sha1 and rsa-
    sha256.  Signers MUST implement and SHOULD sign using rsa-sha256.
    Verifiers MUST implement both rsa-sha1 and rsa-sha256.

       INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some
       senders might prefer to use rsa-sha1 when balancing security
       strength against performance, complexity, or other needs.  In
       general, however, rsa-sha256 should always be used whenever
       possible.

and I think it will apply to the shift to stronger (& more overhead) 
hashes. I just don't want to invalid a perfectly good SHA1 hash UNLESS 
the author says so.  What is the SHA1 considered "bad?" or "hacked?" 
What if its a trusted Domain?  Does it apply, with SHA1 at a minimum?

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Jun 2017 19:20:00 -0400

> want to kill it, we should just kill it.

Unless whitelisted, this will create invalid SHA1 signatures from 
perfectly good domains.  New systems who initially avoid SHA1 legacy 
support will quickly learn not all systems use SHA256. i.e a quick 
support problem.

No thanks.

-- 
HLS

---

From: Seth Blank <[email-masked]>
Date: Tue, 20 Jun 2017 16:38:36 -0700

On Tue, Jun 20, 2017 at 4:20 PM, Hector Santos <[email-masked]> wrote:

> support will quickly learn not all systems use SHA256. i.e a quick support
> problem.
>

To me, this is exactly the point. People have had ten years to switch to
SHA-256. At this point, people will only move if the threat of breakage is
upon them. And this isn't breakage, this is a document that says using
SHA-1 is no longer acceptable, and you MUST use SHA-256. If it's the right
security recommendation, we should say it explicitly.

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Jun 2017 19:49:49 -0400

On 6/20/2017 7:38 PM, Seth Blank wrote:
> On Tue, Jun 20, 2017 at 4:20 PM, Hector Santos <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     perfectly good domains.  New systems who initially avoid SHA1
>     legacy support will quickly learn not all systems use SHA256. i.e
>     a quick support problem.
>
>
> To me, this is exactly the point. People have had ten years to switch
> to SHA-256. At this point, people will only move if the threat of
> breakage is upon them. And this isn't breakage, this is a document
> that says using SHA-1 is no longer acceptable, and you MUST use
> SHA-256. If it's the right security recommendation, we should say it
> explicitly.

My point is the protocol/document should also discuss how to deal with 
SHA1 legacy operations when dealing with a migration design issue, not 
ignore its existence, i.e. kill it, wipe it out, remove it from 
discussion.  New verifiers following such advice may quickly see a 
problem when they see SHA1.   Should the document suggest to 
invalidate them?  Can a key lookup or DMARC lookup enforce this? 
(Preferred)    If SHA1 can be exploited for a domain, then the domain 
should be able to provide a hint to the verifier about its validity. 
Or should a verifier just completely ignore it, therefore inherently 
invalidating the signature for lack of SHA1 support?

-- 
HLS

---

From: Jim Fenton <[email-masked]>
Date: Tue, 20 Jun 2017 16:53:53 -0700

> SHA-256. If it's the right security recommendation, we should say it
The verb "use" isn't precise enough because it doesn't specify whether
it refers to signing or verifying.

I agree that the document should say that signers MUST NOT sign using
SHA-1. Even though SHA-1 hasn't been broken seriously enough to be
exploitable in this application, it's good for us to be out in front of
that.

Several people have said that it doesn't matter whether we say MUST NOT
verify rsa-sha1 or SHOULD NOT verify rsa-sha1. That may very well be
true, but we shouldn't be in the habit of saying MUST NOT for something
that is actively being used and is not currently exploitable. We should
be paying at least lip service to interoperability by saying MUST NOT
sign prior to saying MUST NOT verify.

Any signers that are concerned about downgrade attacks (bad actors
creating valid rsa-sha1 signatures somehow, despite the domain using
rsa-sha256) should put h=sha256 in their key records to close that
possibility.

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Jun 2017 20:11:28 -0400

> invalidating the signature for lack of SHA1 support?

I think it would be useful for DMARC feedback reporting to be extended to 
include the signing algorithm used, but that's off topic for this working 
group.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Jun 2017 20:24:55 -0400

On 6/20/2017 7:53 PM, Jim Fenton wrote:

> exploitable in this application, it's good for us to be out in front
> of that.
>
> Several people have said that it doesn't matter whether we say MUST
> NOT verify rsa-sha1 or SHOULD NOT verify rsa-sha1. That may very well
> be true, but we shouldn't be in the habit of saying MUST NOT for
> something that is actively being used and is not currently
> exploitable. We should be paying at least lip service to
> interoperability by saying MUST NOT sign prior to saying MUST NOT verify.
>

+1.

If the document were to suggest "Keep in mind, future Verifiers MAY 
NOT support SHA1"  then this may enough of an incentive for new and 
old signers to begin avoiding SHA1, even for the smallest of DKIM 
applications.

The "higher coverage" verifier will most likely keep SHA1 simply to 
avoid any future support issues. Therefore, it would really help via 
policy to give the verifier what is to be expected.  The key "h=" 
protocol information should be updated to help in this area.

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 21 Jun 2017 00:40:35 +0000

> want to kill it, we should just kill it.

Yes there have been enough documents, for a long enough time, that says "don’t use SHA1"

Yet another document saying might not change things very much.  But yet another document saying "think about doing it" will change nothing.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Jun 2017 00:43:43 +0000

>protocol information should be updated to help in this area.

I think just using the tag in key records operationally is all that's needed.

Also, when it comes to migration away from rsa-sha1, it looks like you're one of the ones with work to do:

DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1;

Scott t

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Jun 2017 21:15:27 -0400

> DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1;

Plus any customers who decided to keep a lower overhead DKIM/SHA1 
email operation running for their setup.  Its just a simple switch for 
us, but I am thinking about the "other legacy endpoints" and the 
customers who may encounter new "support issues" because of an update 
to a version where SHA1 support may have been removed.  Therefore I 
can't turn it off even I changed it for my own setup. But I can help 
with a new possible migration/enforcement option such as:

    [X] If Key has "h=sha256", invalidate an SHA1 signed message
         from the signer domain.

And with a protocol change note such as:

      "Notes: 1) Future Verifiers MAY NOT include support SHA1.

              2) If the signer domain key has "h=sha256" then
                 any signed message not sha256 SHOULD be
                 invalidated.

it should be incentive for signers to begin avoiding sha1 and new 
defaults for signer setups with will be SHA256.

But I think it is important for such language as #2 because this is 
both a security and a migration problem.   If we are here to seek a 
change, then signers needs a quick way to tell verifiers to 
discard/invalidate SHA1 signatures.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 21 Jun 2017 16:33:02 -0000

In article <[email-masked]> you write:
>I agree that the document should say ...

If you don't like what draft-ietf-dcrup-dkim-crypto-02 says, please send text.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 21 Jun 2017 16:35:09 -0000

>I think just using the tag in key records operationally is all that's needed.

I agree.  That's exactly what the h= tag in the key record has always been for.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Fri, 23 Jun 2017 14:20:05 -0700

On Tue, Jun 20, 2017 at 6:15 PM, Hector Santos <[email-masked]> wrote:

> Plus any customers who decided to keep a lower overhead DKIM/SHA1 email
> operation running for their setup.  Its just a simple switch for us, but I
> am thinking about the "other legacy endpoints" and the customers who may
> encounter new "support issues" because of an update to a version where SHA1
> support may have been removed.  Therefore I can't turn it off even I
> changed it for my own setup. But I can help with a new possible
> migration/enforcement option such as:
>

Isn't that just a truism?  Ie, any signing algorithm may be invalidated in
the future.  We're explicitly trying to move the needle away from SHA-1
right now, not in the future.

Brandon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Jun 2017 18:39:23 -0400

In general MAY NOT is to be avoided as ambiguous. RFC 2119 does not permit
it as normative text.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 26 Jun 2017 11:46:33 -0700

> If you don't like what draft-ietf-dcrup-dkim-crypto-02 says, please send text.

Good idea. I'm changing the subject line because this is a general
review rather than specific to that particular point.

Section 3 paragraph 1: It might be a good idea to have a forward
reference to Section 4 for "k=eddsafp" and rsafp since it hasn't been
introduced yet. It might also be a good idea to make ABNF to optionally
append "fp" or "-fp" to any of the signing algorithms since the use of
fingerprints is orthogonal to the signing algorithm, in the same way
that the choice of hash is.

Section 4:

- Is the algorithm used to hash the key always SHA-256, or should there
be a tag for algorithm choice for that too? SHA-256 looks pretty good
now, but who knows if that will change at some point.

- Paragraph 1, since the hash and signature algorithms are orthogonal,
suggest "Signing Algorithm is rsafp" and "Signing Algorithm is eddsafp".
But also see above comment above about making the "fp" part independent.

- After paragraph 1, there is an abrupt transition between k=rsafp or
k=eddsafp and the next paragraph where k= contains the public key. It
should make it clear in the first paragraph that it is talking about the
DNS record containing k=rsafp etc. and in the second case it is talking
about a new tag/value in the signature itself.

- It appears that the only indication in a signature whether it is using
keys or key fingerprints published in DNS is the presence or absence of
a k= tag/value in the signature. Is that a good idea, or should there be
something more explicit?

Section 5:

- Paragraph 2, rsafp-256 -> rsafp-sha256. Might also want to reinforce
that signers MUST implement rsa-sha256.

- I'm having trouble with all the use of "MUST NOT implement" in
paragraph 2. We're concerned with what they actually use, not what their
implementations are capable of (paragraph 3 is worded better).

- My suggestion for paragraph 2:

Signers MUST NOT use the sha1 hash algorithm in generating signatures.
Verifiers MAY accept signatures generated using the sha1 hash algorithm,
although the use of that algorithm is deprecated due to its known
security weaknesses. Verifiers MUST be capable of verifying signatures
generated using the sha256 hash algorithm. Verifiers MUST be capable of
verifying the rsa, rsafp, eddsa, and eddsafp signature algorithms.

Section 7:

Since this is removing sha1 support, the security considerations should
say something about that.

-Jim

---

From: "John R. Levine" <[email-masked]>
Date: 28 Jun 2017 15:58:55 +0200

> review rather than specific to that particular point.

Thanks, will take another whack at it when time permits.

> introduced yet.

Sure.

> It might also be a good idea to make ABNF to optionally

I don't see what problem this solves.  If we add new algorithms we'll need 
a new draft, and we can decide whether to add fp versions.

It also occurs to me that eddsafp offers no benefit relative to eddsa 
since the key fingerprint is longer than the key, so I'm thinking the 
fingerprint option should only be for RSA.  That's one less signature 
variant to implement and test.

> now, but who knows if that will change at some point.

Same thing, if we need to change we'll have a draft that adds whatever we 
need to add.  If we add new key hashes, backward compatibility will mean 
that an unspecified hash is SHA-256, just like a missing k= means the 
algorithm is RSA.  Or by the time SHA-256 is too weak, maybe everone will 
have moved to eddsa and we just deprecate RSA signatures, with or without 
key hashes.

> about a new tag/value in the signature itself.

OK.

> a k= tag/value in the signature. Is that a good idea, or should there be

It'll also say a=rsafp-sha256 rather than a=rsa-sha256.

> verifying the rsa, rsafp, eddsa, and eddsafp signature algorithms.

I'm OK with MUST NOT use rather than MUST NOT implement, but for 
interoperability I think verifiers SHOULD NOT implement sha1 or maybe 
SHOULD NOT accept is correct.  SHOULD NOT means don't do it unless you 
understand the consequences which seems right.

> say something about that.

Good point.  This elucidates the SHOULD NOT above.

R's,
John