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

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

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

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

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

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

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

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

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

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

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

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, no

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

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

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

On Mon, Jan 11, 2016 at 6:01 PM, Peter Gutmann wrote: > 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

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

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 onl

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

On 1/11/16 at 4:32 PM, watsonbl...@gmail.com (Watson Ladd) wrote: 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? The best way I can think of is to test to see if the check

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

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 Sen

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

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

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 th

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

> (Please let's not re-open that thread). Indeed, let's agree to disagree on this. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Viktor Dukhovni Sent: Monday, January 11, 2016 3:43 PM To: tls@ietf.org Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 an

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

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

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

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

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

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

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

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 Chro

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

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

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

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 p

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

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 depen

Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01

On Mon, Jan 11, 2016 at 12:12:47AM -0800, Watson Ladd wrote: > On Mon, Jan 11, 2016 at 12:03 AM, Ilari Liusvaara > > > > I don't think this is signficant. If you want protection from THS that > > actually works, you require EMS anyway (or ensure THS is of no > > consequence at application layer), n

Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01

On Mon, Jan 11, 2016 at 12:03 AM, Ilari Liusvaara wrote: > On Mon, Jan 11, 2016 at 09:28:57AM +0200, Ilari Liusvaara wrote: >> On Sun, Jan 10, 2016 at 07:53:08PM -0800, Joseph Salowey wrote: >> > Please respond if you have concern about early code point assignment for >> > the curves listed in dra

Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01

On Mon, Jan 11, 2016 at 09:28:57AM +0200, Ilari Liusvaara wrote: > On Sun, Jan 10, 2016 at 07:53:08PM -0800, Joseph Salowey wrote: > > Please respond if you have concern about early code point assignment for > > the curves listed in draft-ietf-tls-curve25519-01 > >