Subject: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Wed, 12 Jul 2017 09:22:52 -0700

Spencer Dawkins has entered the following ballot position for
charter-ietf-dcrup-01-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-dcrup/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm fine with doing this, without external review.

I'm a Yes for this one, but Alexey needs to be a Yes before it's approved, of
course. But definitely the right thing to do.

I did see

    DKIM also currently supports use of SHA1 coupled with RSA.  SHA1 has been
        formally deprecated due to weakness especially when used in the context
        transport security, though the risk of a successful preimage attack is

I may be unaware of a well-known term of art, but I'm guessing "context
transport security" is missing "of" (so, "context of transport security")?

        less severe.  Still, the community wishes to discourage its continued
        use in the DKIM context.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Jul 2017 10:13:39 +1000

On 13 July 2017 at 02:22, Spencer Dawkins <[email-masked]> wrote:
> [...]

Spencer was lucky enough to highlight some text that is incorrect,
possibly in multiple ways.

> SHA1 has been formally deprecated due to weakness especially when used in the context transport security, though the risk of a successful preimage attack is less severe.

The use of SHA-1 for transport security (here I believe this means
TLS), is for three things.  The first of these is in the context of
record protection, which is HMAC SHA-1.  The second is the PRF, which
also uses HMAC.  To the best of my knowledge, use of SHA-1 with HMAC
isn't completely and utterly busted.  Not to say that I would trust
it, of course.

The other use of SHA-1 is with signatures.  In that context, it is
very much busted. And the use of SHA-1 in signatures in TLS is quite
similar to the use of SHA-1 in DKIM.

Also, the attack on SHA-1 is a collision attack.  My understanding is
that first and second preimage attacks are still a ways from being
practical.  (Hence HMAC remaining vaguely usable.)  The text
specifically uses the word "preimage", which is wrong.  Well, unless
there is an unwritten assertion that preimage attacks are necessary to
attack DKIM, which would need better substantiation.

Finally, it's not clear what context the text refers to when it talks
about the risk being less severe.  However, I think that the weak
point in both cases is roughly the same.  That TLS has a use of SHA-1
that isn't as busted doesn't make it any less a problem.

Drop the tail of the sentence.  That is, everything after the comma.
My suggestion:

> SHA1 has been formally deprecated due to weakness in numerous contexts.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Jul 2017 16:30:27 +0200

On Thu, Jul 13, 2017 at 2:13 AM, Martin Thomson <[email-masked]>
wrote:

> > SHA1 has been formally deprecated due to weakness especially when used
> in the context transport security, though the risk of a successful preimage
> attack is less severe.
>

I provided the cited text, and I recall it was based on something I think
Eric said along the lines of "there are no known preimage attacks against
SHA1 (yet)."  It's totally possible I misunderstood him, not being a
security expert.

> attack DKIM, which would need better substantiation.

Given DKIM signatures are just classic encrypt-the-digest kind of thing,
and the keys and most other properties can be controlled or are constant, I
assumed that the only possible attack is a preimage attack on the digest
function.  And if there are no known preimage attacks on SHA1 (yet), then I
took Eric's remark to mean there's not much to worry about here; of course,
the WG is free to decide to deprecate SHA1 out of an abundance of caution
anyway, which is what I was trying to convey in that language.

> > SHA1 has been formally deprecated due to weakness in numerous contexts.

That's fine with me, I guess, conceding apparent ignorance of the deeper
details.

-MSK

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jul 2017 16:44:58 +0200

> SHA1 (yet)."  It's totally possible I misunderstood him, not being a

He is right, as of today, there are no known, practical preimage
attacks (either first or second) against SHA-1.  This is perhaps why
certain uses of SHA-1 are OK(ish), like HMAC.

> And if there are no known preimage attacks on SHA1 (yet), then I took Eric's remark to mean there's not much to worry about here [...]

Second preimage attacks would be a real problem, yeah.  That doesn't
mean that a collision can't be exploited (but I am not a
cryptographer).

> That's fine with me, I guess, conceding apparent ignorance of the deeper

:)

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jul 2017 14:56:09 +0000

Everyone's moving away from SHA1 in anticipation of it falling.  The charter change just wants to let DKIM join the cool kids.  This is easier, rather than requiring DNS people to repeatedly explain why "it's okay we don't have to do it"

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Jul 2017 16:56:37 +0200

> mean that a collision can't be exploited (but I am not a

I infer from this that "preimage attack" and "collision" are in fact
different things, which isn't what I believed before.  Time to go do some
reading.

-MSK

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Jul 2017 08:06:02 -0700

Correct.

Collision refers to finding two messages M1 and M2 st. H(M1) == H(M2)
First preimage refers to starting with some value X and computing a message
M st. H(M) == X
Second preimage refers to starting with some message M and computing a new
message M' st. H(M') == HJ(M)

-Ekr

On Tue, Jul 18, 2017 at 7:56 AM, Murray S. Kucherawy <[email-masked]>
wrote:

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

---

From: denis bider <[email-masked]>
Date: Tue, 18 Jul 2017 09:23:42 -0600

To elaborate a bit - collision allows things like an adversary submitting a
specially crafted certificate signing request for my.example.com, which
happens to have the same hash as a hidden twin crafted request for
google.com. The CA signs the certificate for my.example.com, but because of
the weakness of the hash, the same signature is now also valid for the
hidden twin crafted request. The adversary combines the signature with the
hidden request, and gets a valid certificate for google.com.

DKIM does not fatally suffer from this because the entity generating the
messages also signs them. If someone wants to fool around and generate M
and M' with same hash, and sign them using DKIM, there is no real
consequence for DKIM's main security objective (which is to verify the
message is from the domain it claims it is).

But, if someone were to discover a preimage attack, DKIM's main security
objective would no longer be met, since other people besides the original
signer would be able to generate messages M', M'', M''' that appear to be
sent from the signer's domain.

On Tue, Jul 18, 2017 at 9:06 AM, Eric Rescorla <[email-masked]> wrote:

> First preimage refers to starting with some value X and computing a
> message M st. H(M) == X
>> On Tue, Jul 18, 2017 at 4:44 PM, Martin Thomson <[email-masked]
>> > wrote:
>>