Subject: [Dcrup] Time For People To Really Stop Using SHA-1 Signatures?

From: Scott Kitterman <[email-masked]>
Date: Tue, 07 Jan 2020 18:41:09 -0500

https://sha-mbles.github.io/

If I'm reading this right, the last excuse that still trusting SHA-1 DKIM 
signatures is an OK thing to do is gone.  Comments from anyone that really 
understands thus stuff would be appreciated.

Thanks,

Scott K

---

From: Russ Housley <[email-masked]>
Date: Tue, 7 Jan 2020 19:03:37 -0500

> understands thus stuff would be appreciated.

Here is the research paper: chttps://eprint.iacr.org/2020/014

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 7 Jan 2020 19:46:40 -0500

> understands thus stuff would be appreciated.

Well, weak DKIM signatures create the possibility of message forgery, where a
signed message from the attacker can later be replaced by another signed
message.  But if the attacker can post messages via your server, he would
in most cases just post the ultimately desired message.

Supposing however that for some reason modified message replay is an appealing
attack, then the attacker needs to be able to mount the SHA-1 chosen-prefix
attack in the context of a line-oriented message transport where arbitrary
binary data can be tricky to embed in the message.

So I don't think there's a crisis that requires drop-everything urgent action,
but indeed this would be a good time to start phasing out SHA-1 signatures,
if you have not done so already.

-- 
    Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 10 Jan 2020 16:21:58 -0800

> understands thus stuff would be appreciated.

I can't say that I fully understand how a chosen-prefix collision
affects security of DKIM but...

We've always asserted that DKIM provides limited security because of its
dependence on DNS for publication of public keys. I don't think that
this attack on SHA-1 changes that much. If someone wanted to spoof
DKIM-signed messages from an arbitrary domain, they would probably look
for a domain publishing a relatively short public key, expend the effort
to factor it, and then they would be able to sign as much email from
that domain as they want, until someone notices and revokes the key.
Creating a new message that has a SHA-1 collision would only allow that
specific message to be signed, and I'd expect it to look pretty strange.

That said, we're in fairly good shape. DKIM has, from its initial
publication, had SHA256 as mandatory-to-implement for both signers and
verifiers. A very unscientific search of my inbox came up with with 8102
instances of SHA256 signatures and 548 instances of SHA-1 signatures
(yes, I have a far too big inbox, and some messages were signed multiple
times). But unfortunately the SHA-1 signatures probably come from a
"long tail" of domains.

Someone with access to a more comprehensive corpus of email than my home
domain might want to catalog and try to contact domains using SHA-1, and
encourage them to change: "some recipients may not trust your DKIM
signatures any more". Some PR (magazine articles, etc.) might help, too.

-Jim

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Jan 2020 20:08:41 -0500

The attack cost $11K.

Seems like that is a more than sufficient proof of work function to send a
message...

And what Jim said. There are some systems that are gonna be clobbered hard.
All the ones that are using SHA-1 certs off delisted roots.

But lets face it work factor of garage door openers is?? 2^20? 2^10

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jan 2020 09:16:00 -0500

> understands thus stuff would be appreciated.

-1 to the subject question.

Comments from implementators who only need to peripherally 
"understand" it, should be commenting.  Did we want a discussion on 
theory?

Despite the paper's claim for a clobbering technique, this is a 
time-shifted application problem -- replays after a secured message 
has been received and maybe not read yet.  If read, expiration 
concepts should apply.  In fact, we should probably be recommending x= 
expiration times.  Right now, the default is off.

    x= Signature Expiration (plain-text unsigned decimal integer;
       RECOMMENDED, default is no expiration).  The format is the same as
       in the "t=" tag, represented as an absolute date, not as a time
       delta from the signing timestamp.  The value is expressed as an
       unsigned integer in decimal ASCII, with the same constraints on
       the value in the "t=" tag.  Signatures MAY be considered invalid
       if the verification time at the Verifier is past the expiration
       date.  The verification time should be the time that the message
       was first received at the administrative domain of the Verifier if
       that time is reliably available; otherwise, the current time
       should be used.  The value of the "x=" tag MUST be greater than
       the value of the "t=" tag if both are present.

But we have a higher potential, replay damage coming from allowing 
5322.From Rewrites to have evolve among some packages.  SHA1 usage is 
the least of my DKIM concerns.

Nonetheless, we are already promoting verify only, not signing.  Is 
that not enough? Or are we now promoting the suggestion to remove SHA1 
from APIs and tools?   I read a statement the OpenSSL folks were 
thinking about removing it. That would be a horrible decision and it 
just someone's belief, not the OpenSSL team because then we really 
create REAL damage by forcing SHA1 signatures fails which are 
otherwise secured right now.

Lets fix the real Rewrite potential problems first before worrying 
about SHA1.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jan 2020 09:44:08 -0500

> signatures any more". Some PR (magazine articles, etc.) might help, too.

I am not too keen with the false reporting and illusion of insecurity 
when it doesn't exist. Its would a lie to say, "Its not secured" and 
in fact, it is.  As stated, DNS has a bigger potential is being a 
major problem for users.  Putting all your faith in a BROWSER or a 
single vendor to "Trust Them" (but you have to pay them first) is a 
bigger risk.

Whether SHA1 usage is 10%, 5% or 1%, we need to remember, it is still 
part of the protocol and DKIM Verifiers MUST be including SHA1 for 
verification purposes.

    https://tools.ietf.org/html/rfc6376#page-13
    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.

Not having it (with suggestions or ideas to remove SHA1 from APIs, 
tools) WILL cause immediate problems.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Jan 2020 09:50:58 -0500

No.  It's not.  Please review RFC 8301, which updates RFC 6376:

> 3.1.  Signing and Verification Algorithms
> 
>    are defined by this specification at this time: rsa-sha1 and
>    rsa-sha256.  Signers MUST sign using rsa-sha256.  Verifiers MUST be
>    able to verify using rsa-sha256.  rsa-sha1 MUST NOT be used for
>    signing or verifying.
>    
>    DKIM signatures identified as having been signed with historic
>    algorithms (currently, rsa-sha1) have permanently failed evaluation
>    as discussed in Section 3.9 of [RFC6376].

I know you know this, so please stop pretending it's not true.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Jan 2020 09:58:27 -0500

> I know you know this, so please stop pretending it's not true.

At some point you are going to have to actually implement sha-256:

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

You're close to a decade and a half late.

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 14 Jan 2020 16:26:56 +0000

As I recall, we had extended discussion about MUST NOT SHA1 and Hector was the only one opposed to dropping SHA1.  We also discussed changing the version number because of changing the  crypto, and while there were a couple of people who were sympathetic to the view, this was not done.

>    I know you know this, so please stop pretending it's not true.

Hector, I do not know what you actually know, but please keep this reminder, and Scott's in mind.  Repeating "sha1 is still in the standard" is wrong.  And if you forgot, now you know.  Please stop, you are hurting the Internet (and those who read mail archives to see what's going on).

	/r$, co-chair.

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jan 2020 12:29:27 -0500

> Hector, I do not know what you actually know, but please keep this reminder, and Scott's in mind.  Repeating "sha1 is still in the standard" is wrong.  And if you forgot, now you know.  Please stop…

I am not "hurting the internet.  You would be "hurting the internet" 
if you promoted the idea of pulling SHA1 from the tool set because you 
would be causing immediate fails where as today, there is no failure.

And BTW, I was practically the only one who was advocating DKIM Policy 
since the beginning. It was a lonely world, trust me,  and since I was 
the practically the only one, ADSP was abandoned only to be replaced 
with the same issue and problems, and its not even a proposed standard 
and look at the potential replay problems will can have with Rewrites. 
  Today how much DKIM POLICY has grown and I always felt it would 
grow.  So I don't buy "I am the only one." I may be the only one to 
dare speak up.

So please don't get mad at me. my engineering and security position 
was clear than and it is clear now.  It would be a mistake for SHA1 to 
be pulled from APIs and Tools. If you do it with OpenSSL, since you 
privy to the team,  I think it would be YOU who would be hurting 
implementers, developers, products vendors, customers and the INTERNET.

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 14 Jan 2020 17:32:14 +0000

Hector,

Thank you for your efforts.

The WG decided that the standards-track is to move away from SHA1.  Saying otherwise sows confusion; please stop.

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jan 2020 12:43:47 -0500

> At some point you are going to have to actually implement sha-256:

Our Wildcat! DKIM package included SHA256 since day one

> You're close to a decade and a half late.

Hmmm, I believe you knew the above and the reasons why I have SHA1 here.

SHA1 was intentional set for my isdg.net domain -- on purpose.  I 
wanted to see where were these clobbering problems.  Where is this 
SHA1 clobbering in the last 15 years?   Use this this "new method" on 
my mail.

Again, I always supported the deprecation - verify support.  I don't 
support outright pulling of SHA1 from DKIM specification, nor APIs. 
OpenSSL would be making a major "internet hurting" mistake if they do.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jan 2020 13:13:28 -0500

> The WG decided that the standards-track is to move away from SHA1.  Saying otherwise sows confusion; please stop.

Aw come on. Give people more credit, ok? I doubt it will confuse 
anyone but your reaction certainly is.

I am not trying to resurrect SHA1.   What was the point of this thread?

No one every disputed SHA1 was potentially vulnerable. So was the 
question if this new method made a difference?  Not to me.  But if I 
read the article right,  I read something about the OpenSSL team using 
the new clobber method as justification to remove it from the API. 
Was that the goal here? And for Developers to finally remove it from 
their implementations?  If so, hear me now -- I strongly believe it 
would be mistake at multiple levels to pull SHA1 from DKIM and APIs. 
It will instantly cause problems -- immediately.  That's "Hurting the 
Internet' so how dare you say I will be hurting the internet and 
confusion others.   Even if it is pulled from OpenSSL, I will add it 
back in promoting API deviations which I hate to do.

For this WG and in older DKIM WG, as I stated always, I supported the 
deprecation -- always day one, but not the removal. That is why the 
STD is written as it is-- it was the consensus.   Today, nothing has 
changed but this WG wanted to do a new hash which loads high overhead 
on others, and also remove SHA1.  You can mandate it with WG but I 
disagree with the idea of a complete removal.  I am not about to 
remove sha1 from my package by virtual of a future OpenSSL removing 
it, and then have to endure immediate support issues and reports from 
a customer complaining about some new DKIM failure they never had before.

I'm done with this one.

-- 
HLS

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Jan 2020 17:26:10 -0500

On Tue, Jan 14, 2020 at 09:16:00AM -0500, Hector Santos wrote:

> I read a statement the OpenSSL folks were thinking about removing it.

There are no such plans.  Rather, in some future releases the use of
SHA-1 in digital signatures (whether in X.509, or in TLS handshake
signatures) will probably only work at "security level 0".

The default security level for TLS is level 1 (notionally 80 bits),
which currently admits SHA-1.  When/if SHA-1 is downgraded (not
removed) X.509 certificates using SHA-1 will fail to validate at
level 1, and TLS handshake signatures using SHA1, MD5 or SHA-1||MD5
will not be considered valid.  That effectively rules out TLS 1.0
and TLS 1.1.  So the change would need to made with care, giving
the laggards some time to finally migrate to TLS 1.2.

Non-TLS applications default to level 0 (no floor on algorithm
strength), but can choose a stricter level for certificate verification.

HMAC-SHA1 remains unbroken, and so there are no plans to deprecate
SHA-1 ciphersuites from TLS, but these days you're more likely to
negotiate an AEAD cipher.

> That would be a horrible decision and it just someone's belief, not
> the OpenSSL team because then we really create REAL damage by forcing
> SHA1 signatures fails which are otherwise secured right now.

Let's not fill the void with wild speculation.

> Lets fix the real Rewrite potential problems first before worrying 

This isn't an either/or choice, deprecate SHA1 signing, *and* other
issues that warrant attention.

-- 
    Viktor.