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

[Peter Gutmann]

Kurt Roeckx  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[David Benjamin]

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  wrote:

> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

On Mon, Jan 11, 2016 at 11:38:25PM +, Andrei Popov wrote:

> 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."

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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

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:tls-boun...@ietf.org] On Behalf Of Yuhong Bao
Sent: Monday, January 11, 2016 3:30 PM
To: David Benjamin ; Kurt Roeckx ; 
tls@ietf.org
Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

> (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.  
___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls=01%7c01%7cAndrei.Popov%40microsoft.com%7cdca8115118694f6fd88808d31adf1a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1=NMe0Q4tKP6RdFTuDEkKavQF4YysdBEBX%2ftX4u1SEw7o%3d

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Mon, Jan 11, 2016 at 3:09 PM, Peter Gutmann
 wrote:
> Kurt Roeckx  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.

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?

>
>>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".

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.
>
> 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.

That's because real cryptographers understand that this is only 64
times better then SHA1, and so don't bother to mention it.
>
> Peter.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 12 January 2016 at 05:30, Kurt Roeckx  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.


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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

David Benjamin  writes:

>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.

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.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

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:tls-boun...@ietf.org] On Behalf Of Martin Thomson
Sent: Monday, January 11, 2016 4:33 PM
To: Kurt Roeckx 
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

On 12 January 2016 at 05:30, Kurt Roeckx  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.


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.

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls=01%7c01%7cAndrei.Popov%40microsoft.com%7c6fb3e54eee074bb130fc08d31ae7f945%7c72f988bf86f141af91ab2d7cd011db47%7c1=1VqipRFwf5mpoYunrkaM3Uy%2f22nZWtMGg5m27W72aBU%3d

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Viktor Dukhovni]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Tony Arcieri]

On Mon, Jan 11, 2016 at 9:32 PM, Viktor Dukhovni 
wrote:

> > 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.


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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

Watson Ladd  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Loganaden Velvindron]

On Tue, Jan 12, 2016 at 3:42 AM, Dave Garrett  wrote:
> On Monday, January 11, 2016 06:13:37 pm Tony Arcieri wrote:
>> 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.
>
> 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].
>

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


> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

Watson Ladd  writes:

>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.

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

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Samuel Neves]

On 12/01/2016 02:03, Watson Ladd wrote:
> However, free-start collisions have been found, as have ways to modify
> constants in the SHA-1 IV to get collisions.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Dave Garrett]

On Tuesday, January 12, 2016 12:32:08 am Viktor Dukhovni wrote:
> > 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.

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.

> > 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.

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.

> > 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.

Ah, good to hear. Thanks for the info.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kurt Roeckx]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls