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

Joseph Salowey writes: > Please respond if you have concern about early code point assignment for > the curves listed in draft-ietf-tls-curve25519-01 > . The above draft, and rfc4492bis and tls13-11, has known

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

> I'm aware of that (and related) work, but this is about finding > 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

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

> 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

[TLS] Fixing TLS

Martin's comment reminded me of the following that I've been meaning to post... In a recent discussion among some crypto folks, the topic of what TLS 1.3 could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.

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

On Tuesday 12 January 2016 14:24:31 Martin Rex wrote: > Tony Arcieri wrote: > [ Charset UTF-8 unsupported, converting... ] > > > Peter Gutmann wrote: > >> The vulnerabilities shown in the SLOTH paper were based on the fact > >> that implementations still allow MD5 for

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

Karthikeyan Bhargavan writes: >Coming back to digital signatures, all uses of weak hash functions are >essentially broken. Not necessarily. Use of weak hash functions where the attacker has time to do offline precomputations/calculations are essentially broken.

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

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

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

On Monday 11 January 2016 17:28:33 Bill Frantz wrote: > 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

Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

Adam Langley writes: > Curve25519, as the name suggests, operates on 255-bit numbers. When > encoded as bytes, there's obviously a 256th bit that needs to be > specified. > > Curve25519 implementations didn't set the bit but did used to vary on > how they parsed it. Some

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote: > On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrote: >> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: >>> Martin's comment reminded me of the following that I've been meaning to >>>

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 12:27 PM Peter Bowen wrote: > The gaps seem to be: > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > (BoringSSL has an implementation using cipher suite 0xca,0xfe) > 0xca,0xfe has since been removed as nothing was using it. I'm not

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

The same concern still applies: what does it mean to allocate code point for the 4492bis-05 description? The document currently says to reject invalid ECDH keys, but I believe we want to remove that text. We could ask Yoav to issue a 4492bis-06 quickly that fix this issue, and then proceed with

Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote: > On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett > wrote: > > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > > > > I'll be the bearer of bad news and tell you that your proposal has come up > > in

Re: [TLS] Server behavior when client certificate does not match the request ?

On Tue, Jan 12, 2016 at 1:30 PM, Fabrice Gautier wrote: > On Tue, Jan 12, 2016 at 1:13 PM, Eric Rescorla wrote: > > > > > > On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier < > fabrice.gaut...@gmail.com> > > wrote: > >> > >> Hi, > >> > >> TLS 1.2 RFC

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: > > > On 12 Jan 2016, at 9:26 PM, Simon Josefsson wrote: > > > > The same concern still applies: what does it mean to allocate code > > point for the 4492bis-05 description? > > Allocating code points just means an

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

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

Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote: > On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote: > > I hope that Google's efforts to get QUIC as-is specced out go quickly and > > smoothly, and that it can be used as a basis to develop an official total > > TCP/TLS

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 12:33 PM, Dave Garrett wrote: > On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote: > > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox > wrote: > > > I wish that were the plan (to upgrade QUIC crypto and eventually

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote: > On Tue, Jan 12, 2016 at 11:39 AM, Dave Garrett > wrote: > >> On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote: >> >> Personally, I hope this new version of TLS, save for possibly some

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 12:18 PM, Tony Arcieri wrote: > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote: > >> I wish that were the plan (to upgrade QUIC crypto and eventually make >> that the new crypto platform). If I am not mistaken, QUICK crypto

[TLS] Server behavior when client certificate does not match the request ?

Hi, TLS 1.2 RFC says that a a client certificate MUST be compatible the parameters specified in the Certificate Request: key type, hash/signature algorithm and CA. If a client does not have such a compatible cert, it MUST send an empty Certificate message. In practice, what is a common behavior

Re: [TLS] Fixing TLS

> I hope that Google's efforts to get QUIC as-is specced out go quickly and > smoothly, and that it can be used as a basis to develop an official total > TCP/TLS replacement. If this were the path forward (and I doubt that it is), I would very much prefer Peter Gutman's evolutionary TLS 1.3.

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 11:27:02AM -0800, Bill Cox wrote: > > I'll just second what David said here. 0-RTT mode is here to stay, and I > don't see a simple upgrade path from TLS 1.2. Speed matters, and 0-RTT is > a huge upgrade for users. The trick is doing this securely... And I think

Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote: > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote: > > I wish that were the plan (to upgrade QUIC crypto and eventually make that > > the new crypto platform). If I am not mistaken, QUICK crypto is going to >

Re: [TLS] Server behavior when client certificate does not match the request ?

On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier wrote: > Hi, > > TLS 1.2 RFC says that a a client certificate MUST be compatible the > parameters specified in the Certificate Request: key type, > hash/signature algorithm and CA. > If a client does not have such a

Re: [TLS] Server behavior when client certificate does not match the request ?

Fabrice Gautier writes: >"Do TLS libraries act strictly on those requirements, or do they leave it to >the application layers?" > >"How do TLS libraries/server applications act when such requirements are not >respected?" This has already been discussed in the past,

Re: [TLS] Server behavior when client certificate does not match the request ?

On Tue, Jan 12, 2016 at 3:53 PM, Viktor Dukhovni wrote: > On Tue, Jan 12, 2016 at 01:07:16PM -0800, Fabrice Gautier wrote: > >> In practice, what is a common behavior for Servers in the case where >> the client sends an incompatible cert ? Treat it as if there was an >>

Re: [TLS] Server behavior when client certificate does not match the request ?

On Tue, Jan 12, 2016 at 4:13 PM, Fabrice Gautier wrote: > > > With TLS 1.2, where the server does send a supported_signature_algorithms > > list, clients that use signatures other than those listed should > > expect to run into servers that reject this with a fatal

Re: [TLS] Server behavior when client certificate does not match the request ?

On Tue, Jan 12, 2016 at 01:07:16PM -0800, Fabrice Gautier wrote: > In practice, what is a common behavior for Servers in the case where > the client sends an incompatible cert ? Treat it as if there was an > empty cert or an invalid cert ? Fail the handshake ? With TLS 1.0/1.1, in which the

Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > Martin's comment reminded me of the following that I've been meaning to > post... > > In a recent discussion among some crypto folks, the topic of what TLS 1.3 > could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade

Re: [TLS] Fixing TLS

Hi, Peter Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) that this WG is working on right now, why? Other groups are not working on HTTP/1.2 or IKEv1.1 or any other $protocolv$(major-1).$(minor+1). Any TLS library that exists now doesn’t have an implementation of

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 02:03:53PM +, Peter Gutmann wrote: > Martin's comment reminded me of the following that I've been meaning to > post... > > In a recent discussion among some crypto folks, the topic of what TLS 1.3 > could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrote: > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: >> Martin's comment reminded me of the following that I've been meaning to >> post... >> >> In a recent discussion among some crypto folks, the topic of

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 9:13 AM, Yoav Nir wrote: > Hi, Peter > > Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) > that this WG is working on right now, why? > > Other groups are not working on HTTP/1.2 or IKEv1.1 or any other >

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 9:17 AM, Ilari Liusvaara wrote: > > > - Drop 99% of all cipher suites, leaving one traditional one (DHE + > AES-CBC + > > HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + > HMAC- > > SHA2 + ECDSA-SHA2/PSK for auth) as