Subject: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

From: Kurt Roeckx <[email-masked]>
Date: Mon, 11 Jan 2016 19:30:17 +0100

Hi,

After the SLOTH paper, we should think about starting to deprecate
TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS
1.2.

As I understand it, they estimate that both TLS 1.2 with SHA1 and
TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be
broken.  They all depend on the chosen prefix collision on SHA1,
with the MD5 part in TLS 1.0 and 1.1 not adding much.

It seems that disabling SHA1 in TLS 1.2 doesn't buy you anything
unless you also disable TLS 1.0 and 1.1.

Kurt

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Jan 2016 23:09:25 +0000

Kurt Roeckx <[email-masked]> writes:

>After the SLOTH paper, we should think about starting to deprecate TLS 1.0
>and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2.

The vulnerabilities shown in the SLOTH paper were based on the fact that
implementations still allow MD5 for authentication/integrity protection, even
if (for example) it's explicitly disabled in the config.  So the problem
wasn't a fault in the protocol, it's buggy implementations (as it was for ones
that allowed 512-bit keys, non-prime primes, and so on).  Throwing out TLS 1.1
based on this seems rather premature.

>As I understand it, they estimate that both TLS 1.2 with SHA1 and TLS 1.0 and
>1.1 with MD5|SHA1 currently require about 2^77 to be broken.  They all depend
>on the chosen prefix collision on SHA1, with the MD5 part in TLS 1.0 and 1.1
>not adding much.

That's presumably based on Joux' multicollisions paper, which also says that
"We also discuss the potential impact of our attack on several published
schemes. Quite surprisingly, for subtle reasons, the schemes we study happen
to be immune to our attack".

More pragmatically, no-one has ever demonstrated any problem with the MD5 ||
SHA1 construct used in TLS, despite there being obvious problems in MD5 and
SHA1 by themselves.

Peter.

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 11 Jan 2016 15:13:37 -0800

> based on this seems rather premature.

My understanding is TLS 1.2 specifically was amended to allow MD5
signatures even though this was not the case in previous TLS versions, or
at least that was the claim of the miTLS presenters on SLOTH at
RealWorldCrypto 2016.

If this is the case, this seems like a big regression in TLS 1.2.

--
Tony Arcieri

---

From: David Benjamin <[email-masked]>
Date: Mon, 11 Jan 2016 23:17:01 +0000

In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing
around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and
it's likely that enterprise deployments are much worse.

I started gathering numbers on ServerKeyExchange hashes back in November.
The code isn't on Chrome's stable channel yet, but earlier channels say a
bit over 5% of ServerKeyExchanges are signed with SHA-1, which is also
quite high.

I also started probing servers in November and observed:
(a) Servers which always sign SHA-1.
(b) Servers which sign SHA-1 *unless* signature_algorithms omits it. Then
they sign SHA-256!?!!?
(c) Servers which sign SHA-2 but fail if signature_algorithms omits SHA-1.
The ones I looked at were all from serving SHA-1 certificates, so probably
their SSL stack compares certs against sig_algs.

(b) and (c) mean that getting a sense of the true impact will be
complicated until we finish getting SHA-1 certificates out of our system. I
have not dug into what's going on with groups (a) and (b) yet.

This all is not to say we shouldn't phase these out. But I do not expect it
to be a speedy process for browsers.

David

On Mon, Jan 11, 2016 at 1:30 PM Kurt Roeckx <[email-masked]> wrote:

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

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Jan 2016 23:23:20 +0000

David Benjamin <[email-masked]> writes:

>around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and it's
>likely that enterprise deployments are much worse.

Embedded is even worse.  I don't have any figures since it's mostly invisible
stuff, but anecdotally I'd say the bell-curve is centered around TLS 1.0/1.1.

Peter.

---

From: Yuhong Bao <[email-masked]>
Date: Mon, 11 Jan 2016 15:29:41 -0800

> (c) Servers which sign SHA-2 but fail if signature_algorithms omits 
> SHA-1. The ones I looked at were all from serving SHA-1 certificates, 
> so probably their SSL stack compares certs against sig_algs. 
I think SChannel is one of them.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 11 Jan 2016 23:38:25 +0000

Yes, per RFC 5246: 
"   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension."

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Yuhong Bao
Sent: Monday, January 11, 2016 3:30 PM
To: David Benjamin <[email-masked]>; Kurt Roeckx <[email-masked]>; [email-masked]
Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

I think SChannel is one of them. 		 	   		  
_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cdca8115118694f6fd88808d31adf1a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NMe0Q4tKP6RdFTuDEkKavQF4YysdBEBX%2ftX4u1SEw7o%3d

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 Jan 2016 23:43:14 +0000

>    hash/signature algorithm pair that appears in that extension."

Yes.  Though for the record, and as discussed ad nauseam before,
this is a bug in the RFC, and should not be implemented as written.
(Please let's not re-open that thread).

Ideally, at some point SChannel will implement the TLS 1.3 draft
bug fix also for TLS 1.2.

-- 
	Viktor.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 12 Jan 2016 00:30:52 +0000

> (Please let's not re-open that thread).
Indeed, let's agree to disagree on this.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Monday, January 11, 2016 3:43 PM
To: [email-masked]
Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

>    hash/signature algorithm pair that appears in that extension."

Yes.  Though for the record, and as discussed ad nauseam before, this is a bug in the RFC, and should not be implemented as written.
(Please let's not re-open that thread).

Ideally, at some point SChannel will implement the TLS 1.3 draft bug fix also for TLS 1.2.

-- 
	Viktor.

_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cf0ce972e5c7b41e5454f08d31ae0fe01%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1s56rzccDOpU1SudCjc4k1LeVmeVsPxqy6XeGDZhQTM%3d

---

From: Watson Ladd <[email-masked]>
Date: Mon, 11 Jan 2016 16:32:58 -0800

> based on this seems rather premature.

Do the RFCs require the relevant checks or not? And given that
implementations frequently get these sorts of things wrong, how do we
make the standard robust against it?

> to be immune to our attack".

And if you actually read beyond the abstract, you would see that he
never considers the straight up concatenation of MD5 and SHA1 which is
indeed vulnerable, exactly matching the attacks he develops.
> SHA1 construct used in TLS, despite there being obvious problems in MD5 and

That's because real cryptographers understand that this is only 64
times better then SHA1, and so don't bother to mention it.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jan 2016 11:33:11 +1100

> TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS

Let's be clear about this: TLS 1.0 represents far too high a
proportion of our usage to remove it at this point.  TLS 1.2 growth is
still solid, but it really isn't that long ago that we turned on TLS
1.2.

The encouragement we give people to upgrade will remain our best
option until TLS 1.0 usage drops an awful lot.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 12 Jan 2016 00:38:02 +0000

Yes, our telemetry shows the same. The use of TLS 1.2 increases and the use of TLS 1.0 goes down, but it will likely be a while before we can disable TLS 1.0 by default in Windows.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Monday, January 11, 2016 4:33 PM
To: Kurt Roeckx <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

On 12 January 2016 at 05:30, Kurt Roeckx <[email-masked]> wrote:
> After the SLOTH paper, we should think about starting to deprecate TLS 
> 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2.

_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c6fb3e54eee074bb130fc08d31ae7f945%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VqipRFwf5mpoYunrkaM3Uy%2f22nZWtMGg5m27W72aBU%3d

---

From: Bill Frantz <[email-masked]>
Date: Mon, 11 Jan 2016 17:28:33 -0800

>make the standard robust against it?

The best way I can think of is to test to see if the checks are 
being done. For example, if a implementation is supposed to 
check if a number is prime, send a non-prime and see if it takes 
the correct action.

Publicly available test suites would be a good step toward 
implementing this strategy. I will note that as the Javascript 
standards people were developing the ES2015 standard, they 
maintained a test suite which following the evolving standard.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Truth and love must prevail  | Periwinkle
(408)356-8506      | over lies and hate.          | 16345 
Englewood Ave
www.pwpconsult.com |               - Vaclav Havel | Los Gatos, 
CA 95032

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Jan 2016 02:01:55 +0000

Watson Ladd <[email-masked]> writes:

>Do the RFCs require the relevant checks or not?

No, they just specify the algorithms and bits on the wire (with a side-order
of MTI stuff for interoperability).  It's up to implementers to not do stupid
things.

>That's because real cryptographers understand that this is only 64 times
>better then SHA1, and so don't bother to mention it.

If it's so trivial to compromise then why, of all the many, many papers
attacking TLS, has no-one every published an attack based on this?  In fact,
since it's so easy, perhaps you could publish a paper demonstrating it in
practice?

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 11 Jan 2016 18:03:48 -0800

> since it's so easy, perhaps you could publish a paper demonstrating it in

SHA-1 collisions have not yet been found. Marc Stevens has published
algorithms he claims reduce the complexity of finding these collisions
to feasible amounts, but they have not yet been run. However,
free-start collisions have been found, as have ways to modify
constants in the SHA-1 IV to get collisions.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Jan 2016 02:06:57 +0000

Watson Ladd <[email-masked]> writes:

>algorithms he claims reduce the complexity of finding these collisions to
>feasible amounts, but they have not yet been run. However, free-start
>collisions have been found, as have ways to modify constants in the SHA-1 IV
>to get collisions.

I'm aware of that (and related) work, but this is about finding
multicollisions in MD5 || SHA1.

Peter.

---

From: Samuel Neves <[email-masked]>
Date: Tue, 12 Jan 2016 02:26:20 +0000

On 12/01/2016 02:03, Watson Ladd wrote:
> However, free-start collisions have been found, as have ways to modify

To be clear, the research into maliciously altering SHA-1 to make collisions easier changed the K_i constants added
during the rounds, not the IV.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 11 Jan 2016 22:42:45 -0500

> If this is the case, this seems like a big regression in TLS 1.2.

I'd like to propose killing the low hanging fruit first, and then continue to build on top of that.

No sane person disputes that MD5 needs to be eradicated ASAP. We're keeping MD5||SHA1 in old TLS for compatibility and we are well aware that needs to go eventually too. Thus, I suggest we publish an MD5 diediedie standards track RFC to prohibit ALL standalone MD5 use in ALL IETF protocols/standards. Constructions using MD5 with something else (namely MD5||SHA1) would also be explicitly recommended against in existing specifications, and explicitly prohibited in all new drafts (even if unlikely).

Also, when I say "prohibited" here, I mean _completely_. No MD5 function should remain in the relevant codebase; if MD5||SHA1 support is continued, there should be one function that does only that without any way to get a plain MD5 hash. (and no "it's fine for this" junk; non-broken hashes are also fine for that, and if you're wrong, it's safer) There are too many implementation bugs in this realm to not state this explicitly [0].

Note that continued support of trust anchors with MD5 hashes is not dependent on this, as we've already agreed they don't need to be validated. (they need to be phased out, but with less urgency) If used within this specific context, nothing even needs the ability to understand MD5 hashes at all in order to handle these; the certificate as a whole is trusted or not.

Dave

PS
To whomever came up with the "diediedie" term, thank you. ;)

[0] Note the 3 disabled-but-accepted bugs listed here:
https://www.mitls.org/pages/attacks/SLOTH#disclosure

---

From: Yuhong Bao <[email-masked]>
Date: Mon, 11 Jan 2016 19:54:14 -0800

> Note that continued support of trust anchors with MD5 hashes is not dependent on this, as we've already agreed they don't need to be validated. (they need to be phased out, but with less urgency) I…
That being said, I think there are very few of the roots left in Mozilla's root store anyway. Similarly HMAC-MD5 is safe too but the only non-export cipher suite that uses it is the RC4 one anyway.

Yuhong Bao

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 12 Jan 2016 04:24:28 +0000

> Also, when I say "prohibited" here, I mean _completely_. No MD5 function should remain in the relevant codebase; if MD5||SHA1 support is continued, there should be one function that does only that…

I completely agree. At least one open source SSL/TLS implementation is
looking at purging their code of MD5 functions.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 12 Jan 2016 05:32:08 +0000

On Mon, Jan 11, 2016 at 10:42:45PM -0500, Dave Garrett wrote:

> No sane person disputes that MD5 needs to be eradicated ASAP. We're keeping
> MD5||SHA1 in old TLS for compatibility and we are well aware that needs
> to go eventually too. Thus, I suggest we publish an MD5 diediedie standards
> track RFC to prohibit ALL standalone MD5 use in ALL IETF
> protocols/standards. 

With some exceptions, for example:

    * As you note in your last comment, X.509 self-signatures via
    MD5 may continue to be ignored, once MD5 is "banned" in the same
    way that they should have been ignored before it was "banned".

    * S/MIME parsers may continue to parse old S/MIME messages with
      MD/5 signatures.  More generally, Encrypted data at rest may
      need support for MD5 for the lifetime of the data (until
      re-encrypted, ...).

    * PEM files holding RSA private encrypted keys may continue
    to use the legacy MD5-based KDF so that the keys can be
    decrypted.

> Also, when I say "prohibited" here, I mean _completely_.

There is no Internet police, and the IETF does not get to prohibit
the use of MD5, we only get to write protocol standards.

> No MD5 function should remain in the relevant codebase;

In particular the IETF does not get to tell anyone which functions
they get to include in their codebase.  So no IETF document saying
such a thing makes much difference.

> if MD5||SHA1 support is continued,
> there should be one function that does only that without any way to get
> a plain MD5 hash.

This turns out to be a good idea anyway, thus, for example, OpenSSL
1.1.0-apha2 just recently added an EVP_md5_sha1() hash function.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 12 Jan 2016 02:30:20 -0500

> the use of MD5, we only get to write protocol standards.

Of course, but the IETF can state that MD5 is not considered secure, must not be used in any of its old specifications (I do agree that a short list of exceptions will be needed), and put forth a set of basic requirements to continue to use IETF specifications with any intent of considering them even slightly secure. The IETF can't directly enforce this, but plenty of organizations do take this sort of thing seriously, even if others ignore it completely. I would hope that lawyers that wish to reduce their companies' liability for ever-frequent data breaches might pay attention when a primary standards body officially disavows things they're still using as insecure.

> such a thing makes much difference.

It's not a list of demands; it's basic specifications maintenance. It's just a matter of stating what's necessary to avoid well-known security problems when using IETF specs. We know it's a problem and should say so, loudly, on the standards track, as we are well aware that obsolete standards are still in regular use and are dangerous unless their implementations are properly handling all issues discovered since initial release.

I am of course aware that the IETF doesn't like to wade into implementation issues in this kind of detail, but just blaming implementations for screw ups isn't an answer. We should be reliably telling implementors what's needed to avoid them.

The disabled-but-accepted nonsense is a common enough high-risk issue that comes up way too often, and not prominently specifying how to deal with it is irresponsible. An argument could be made for coding/API safety issues like this being in a separate BCP RFC, especially if we actually wanted to cover other things like this, but that's a much larger proposal than what I'm currently talking about.

> 1.1.0-apha2 just recently added an EVP_md5_sha1() hash function.

Ah, good to hear. Thanks for the info.

Dave

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 11 Jan 2016 23:45:50 -0800

> such a thing makes much difference.

Not being the person who called "diediedie", but being in total agreement
with the OP, "diediedie" should represent a "burn notice" from the IETF to
all implementers:

DO NOT DO THIS!!!

Clearly many TLS stacks still implement MD5, and there are no TLS police to
arrest the people who are ignoring the IETF RFCs and still shipping
diediedie-filled crypto, but if we want any modicum of security want any
sort of security guarantees from TLS, all stacks *MUST* abandon MD5 in its
entirety.

-- 
Tony Arcieri

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 12 Jan 2016 09:58:15 +0100

> multicollisions in MD5 || SHA1.

To be clear, there is no published collision on MD5 || SHA1 right now.

In our paper, we only say that *if SHA-1 collisions were to appear* with complexity 2^x, 
then MD5||SHA1 collisions would cost 2^(6+x). Hence, if the current estimate of 2^61 for SHA1
were true, then the cost of MD5||SHA1 is 2^67. 

It is up to protocol designers and implementers to decide whether this is an acceptable security margin.
If we decide to wait for a “real” SHA-1 collision to appear, then we must be prepared for “real” attacks to appear soon after.

Best,
Karthik

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Jan 2016 11:05:05 +0000

A few notes on this:

- Calling for the IETF to do something isn't how it works. People
who want thing X to be done need to write the draft and then see
if it gets support. I suspect an md5-die-die-die draft would get
quite a bit of support but...

- The points Victor made about long-term stored data are valid.
In various cases it simply wouldn't be a good plan to re-encrypt
or re-sign old data. Yes, that stored data may not be as secure
as it once was, but it may be impractical to re-encrypt it all.
The openpgp wg [1] are dealing with this particular issue as they
work to do updates, so feel free to get involved in that debate
there if it's of interest.

- If your envisaged scope is for all IETF protocols, then I'm sad
to say there may be "fun" ahead wrt TCP-MD5 [2] which some routing
folks just won't let die it seems, even though we formally obsoleted
that [3] 5 years ago. (And yes, that really is sad.)

- Lastly, and again if your envisaged scope is to deprecate MD5 for
all IETF protocols then that might better fit the charter of the new
curdle wg. [4] And your draft might be an update to RFC6151 [5] I
guess, depending on how you wrote it.

So by all means, write the draft and post a link to the curdle
list (maybe cc'ing this).

Cheers,
S.

[1] https://tools.ietf.org/wg/openpgp/
[2] https://tools.ietf.org/html/rfc2385
[3] https://tools.ietf.org/html/rfc5925
[4] https://tools.ietf.org/wg/curdle
[5] https://tools.ietf.org/html/rfc6151

On 12/01/16 03:42, Dave Garrett wrote:
>> signatures even though this was not the case in previous TLS
>> versions, or at least that was the claim of the miTLS presenters on
>> SLOTH at RealWorldCrypto 2016.
>> 
> No sane person disputes that MD5 needs to be eradicated ASAP. We're
> keeping MD5||SHA1 in old TLS for compatibility and we are well aware
> that needs to go eventually too. Thus, I suggest we publish an MD5
> diediedie standards track RFC to prohibit ALL standalone MD5 use in
> ALL IETF protocols/standards. Constructions using MD5 with something
> else (namely MD5||SHA1) would also be explicitly recommended against
> in existing specifications, and explicitly prohibited in all new
> drafts (even if unlikely).
> 
> Also, when I say "prohibited" here, I mean _completely_. No MD5
> function should remain in the relevant codebase; if MD5||SHA1 support
> is continued, there should be one function that does only that
> without any way to get a plain MD5 hash. (and no "it's fine for this"
> junk; non-broken hashes are also fine for that, and if you're wrong,
> it's safer) There are too many implementation bugs in this realm to
> not state this explicitly [0].
> 
> Note that continued support of trust anchors with MD5 hashes is not
> dependent on this, as we've already agreed they don't need to be
> validated. (they need to be phased out, but with less urgency) If
> used within this specific context, nothing even needs the ability to
> understand MD5 hashes at all in order to handle these; the
> certificate as a whole is trusted or not.
> 
> 
> Dave
> 
> 
> PS To whomever came up with the "diediedie" term, thank you. ;)
> 
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Jan 2016 14:24:31 +0100 (CET)

Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]
> Peter Gutmann <[email-masked]> wrote:
> 
>> implementations still allow MD5 for authentication/integrity protection,
>> even if (for example) it's explicitly disabled in the config.
>> So the problem wasn't a fault in the protocol, it's buggy implementations
>> (as it was for ones that allowed 512-bit keys, non-prime primes,
>>  and so on).  Throwing out TLS 1.1 based on this seems rather premature.

Actually no, the TLSv1.2 made a few terribly braindead design choices
  - newly introduce raw md5RSA digital signatures into TLSv1.2 in 2008
    where all prior TLS protocol versions, including SSLv3 had been using
    the concatenation SHA-1||MD5
  - making the sha1RSA rather than sha256RSA digital signature algorithm
    the default and mandatory-to-implement algorithm for use with TLSv1.2(!!)
    although it was well-known weaker than the algorithm (SHA-1||MD5)
    in all earlier TLS protocol versions, including SSLv3,
    and in spite of SHA-1 already being officially scheduled for end-of-life
    2 years later (NIST, SP800-57 pt.1 rev2)
    This is ridiculous considering that SHA-256 is mandatory-to-use
    in the TLSv1.2 PRF.
  - failing to adjust the truncation of the HMAC output in the
    TLSv1.2 Finished handshake message to be at least half the size of
    the underlying hash function (SHA-256), see RFC 2104 Section 5:

https://tools.ietf.org/html/rfc2104#section-5

> If this is the case, this seems like a big regression in TLS 1.2.

And a fairly well-known & discussed regression, e.g.

http://www.ietf.org/mail-archive/web/tls/current/msg10664.html

that was subsequently removed in OpenSSL 1.0.1f in January 2014,
i.e. 2 years before the SLOTH paper.

I'm also wondering whether it might be misleading to lump the
(in)significance of the currently known collisions for HMAC-SHA1
and HMAC-MD5 together with the (in)significance for 
(general, low-frequent) digital signatures and together with
PKCS#10 & Certificate-issuance design flaw that enables a
mere collision attack to achieve what would normally require
a successful 2nd preimage attack.

Compare the Security Considerations of rfc2104 for the (in)significance
of current collision attacks for HMAC.

https://tools.ietf.org/html/rfc2104#section-6

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Tue, 12 Jan 2016 14:10:23 +0100

On Tuesday 12 January 2016 05:32:08 Viktor Dukhovni wrote:
> > keeping MD5||SHA1 in old TLS for compatibility and we are well
> > aware that needs to go eventually too. Thus, I suggest we publish
> > an MD5 diediedie standards track RFC to prohibit ALL standalone MD5
> > use in ALL IETF
> > protocols/standards.
> 

in case of digital signatures, that means "lifetime of the data", you 
can't expect them being possible to re-sign

so it must not completely forbid use of MD-5 in implementations of stuff 
like PAdES-A. Though it should strongly recommend allowing its use in 
only *very* specific circumstances.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 12 Jan 2016 14:49:46 +0100

> a successful 2nd preimage attack.

I couldn’t really parse this sentence very well, but here are some clarification.

As far as we know, HMAC-MD5 and HMAC-SHA1 are still sufficiently strong MAC functions,
and their use in the TLS Record is not vulnerable to currently known attacks.

TLS also uses HMAC in other situations though, and those may well be vulnerable to collisions.
In particular, the Finished message in TLS 1.1 is not a strong MAC because it first hashes
the transcript before applying the HMAC. Similarly, the use of truncated HMACs in Finished
breaks tls-unique and weakens the renegotiation indication countermeasure.

Generally, HMAC uses as a MAC is ok, but when used as a hash function is as vulnerable
to collisions as the underlying hash function.

Coming back to digital signatures, all uses of weak hash functions are essentially broken. 
The attacks on certificates were well known, and SLOTH shows that other uses
of digital signatures in many mainstream protocols also require collision resistance.

Best,
Karthik

---

From: Hubert Kario <[email-masked]>
Date: Tue, 12 Jan 2016 15:13:26 +0100

On Tuesday 12 January 2016 14:24:31 Martin Rex wrote:
> >> The vulnerabilities shown in the SLOTH paper were based on the fact
> >> that implementations still allow MD5 for authentication/integrity
> >> protection, even if (for example) it's explicitly disabled in the
> >> config. So the problem wasn't a fault in the protocol, it's buggy
> >> implementations (as it was for ones that allowed 512-bit keys,
> >> non-prime primes,>> 
>   - making the sha1RSA rather than sha256RSA digital signature
> algorithm the default and mandatory-to-implement algorithm for use
> with TLSv1.2(!!) although it was well-known weaker than the algorithm
> (SHA-1||MD5) in all earlier TLS protocol versions, including SSLv3,
>     and in spite of SHA-1 already being officially scheduled for
> end-of-life 2 years later (NIST, SP800-57 pt.1 rev2)

the problem stems from the fact that the same field is used for 
announcing support for signatures in ServerKeyExchange *and* for 
certificates provided by server.

while SKE signatures could have easily been made mandatory to SHA-256 at 
least, the depreciation of SHA-1 signatures for certificates certainly 
wasn't possible at the time - only now we are closing on migration from 
them

so, it was a _bad_ decision, but calling it a "braindead" one is a bit 
over the top, sorry
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Jan 2016 14:14:18 +0000

>Coming back to digital signatures, all uses of weak hash functions are

Not necessarily.  Use of weak hash functions where the attacker has time to do
offline precomputations/calculations are essentially broken.  I'm not saying
"keep on using MD5", but unless your attacker can find collisions in real time
you're still OK while you take time to switch to SHA-2 or whatever.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 12 Jan 2016 15:19:21 +0100

On Monday 11 January 2016 17:28:33 Bill Frantz wrote:
> implementing this strategy.

shameful plug: https://github.com/tomato42/tlsfuzzer and the underlying 
https://github.com/tomato42/tlslite-ng

---

From: Dave Garrett <[email-masked]>
Date: Tue, 12 Jan 2016 11:45:25 -0500

> quite a bit of support but...

I'm just bringing up the idea to see what kind of support there is. I don't particularly want to write up a draft in full on my own without discussing it first.

> there if it's of interest.

Yes, decryption of long term storage would have to be one notable exception. The main concern is is with real time (or near) security protocols like TLS, SSH, & etc.

It's also important to note that just because we shouldn't be doing obsolete and risky things in modern software, that doesn't mean that old software (even if maintained) shouldn't be allowed to exist at all. However, doing both in the same application has proven to be very dangerous. On the client side, having separate legacy clients with no modern support and modern clients with no legacy support would drastically improve security, not to mention force users to actively acknowledge when they're doing something risky. (yes, the server side isn't as simple, nor is this always viable on the client side, either)

> that [3] 5 years ago. (And yes, that really is sad.)

Yeah... stuff like that is why I kinda don't want to write up a whole draft to change the world on my own. ;)

> list (maybe cc'ing this).

Yes, I am aware of the new CURDLE WG. Brining up the idea here first simply made more sense, as MD5 was already coming up in discussion here again. Rich Salz also suggested CURDLE being the ideal place to deal with this topic, and I don't disagree. Near as I can tell, though, TLS isn't directly within its charter and a consensus on what to do for it would have to come out of the TLS WG first before CURDLE would be able to include it in any widespread MD5 I-D.

Dave