Re: [TLS] Thoughts on Version Intolerance

2016-07-21 Thread Dave Garrett
On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote: > On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote: > > Any ClientHello with > 200 Cipher suite code points indicates fairly insane > > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour. > > and which part of

Re: [TLS] HTTP, Certificates, and TLS

2016-07-21 Thread Ilari Liusvaara
On Thu, Jul 21, 2016 at 07:08:04PM +0200, Martin Rex wrote: > Martin Thomson wrote: > > On 21 July 2016 at 18:41, Martin Rex wrote: > >>A server that implements this extension MUST NOT accept the request > >>to resume the session if the server_name extension contains a > >>

Re: [TLS] HTTP, Certificates, and TLS

2016-07-21 Thread Mike Bishop
That argument seems like it would apply to all post-handshake authentication, unless there's something different about that. -Original Message- From: Martin Rex [mailto:m...@sap.com] Sent: Thursday, July 21, 2016 7:08 PM To: Martin Thomson Cc: m...@sap.com;

Re: [TLS] HTTP, Certificates, and TLS

2016-07-21 Thread Martin Rex
Martin Thomson wrote: > On 21 July 2016 at 18:41, Martin Rex wrote: >>A server that implements this extension MUST NOT accept the request >>to resume the session if the server_name extension contains a >>different name. Instead, it proceeds with a full handshake to >>

Re: [TLS] HTTP, Certificates, and TLS

2016-07-21 Thread Mike Bishop
Ah, I was seeing the lower-case version in Appendix A from a quick search. Yes, that one is upper-case. Still, that seems simple enough to handle in whatever discussion of how resumption affects this. If they remain in effect across a resumption, any name in that set could reasonably be

Re: [TLS] HTTP, Certificates, and TLS

2016-07-21 Thread Mike Bishop
I assume you're referring to Section 3, SNI's ServerNameList MUST NOT contain more than one name of a given type? Technically, we're not violating that, since we're not changing SNI. The client requests a single identity in the TLS handshake, which the server provides. Additional identities

Re: [TLS] HTTP, Certificates, and TLS

2016-07-21 Thread Martin Rex
Mike Bishop wrote: > > That means we now have a proposal for carrying both client and server > certificates above TLS, found at > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs. > > We have also discussed that it might be preferable to pull part of this > capability back

Re: [TLS] Thoughts on Version Intolerance

2016-07-21 Thread Hubert Kario
On Thursday, 21 July 2016 12:25:48 CEST Peter Gutmann wrote: > Martin Rex writes: > >Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour. > >X.509v3 certificates can theoretically include CAT MPEGs and amount to > >megabytes. > > We really need a TLS scanner

Re: [TLS] Thoughts on Version Intolerance

2016-07-21 Thread Peter Gutmann
Martin Rex writes: >Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour. >X.509v3 certificates can theoretically include CAT MPEGs and amount to >megabytes. We really need a TLS scanner that does this just to see what happens. When I created that cat-MPEG

Re: [TLS] Thoughts on Version Intolerance

2016-07-21 Thread Ilari Liusvaara
On Thu, Jul 21, 2016 at 10:19:34AM +, David Benjamin wrote: > On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk wrote: > > > On 07/20/2016 05:01 AM, Hanno Böck wrote: > > > On Wed, 20 Jul 2016 11:20:46 +0200 > > > Hubert Kario wrote: > > > > And as Hubert

Re: [TLS] Thoughts on Version Intolerance

2016-07-21 Thread Hubert Kario
On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote: > Hubert Kario wrote: > > Martin Rex wrote: > >> Forget TLS extensions, forget ClientHello.client_version. > >> Both in fundamentally broken, and led to Web Browsers coming up > >> with the "downgrade dance" that is target of the POODLE

Re: [TLS] Thoughts on Version Intolerance

2016-07-21 Thread David Benjamin
On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk wrote: > On 07/20/2016 05:01 AM, Hanno Böck wrote: > > On Wed, 20 Jul 2016 11:20:46 +0200 > > Hubert Kario wrote: > > > >> so it looks to me like while we may gain a bit of compatibility by > >> using extension

[TLS] HTTP, Certificates, and TLS

2016-07-21 Thread Mike Bishop
Hi, folks - Martin and I had come previously to the TLS WG to discuss our work with handling client certificates at the HTTP layer. Based on that discussion, we revised our model to cover signatures of an exporter value and carry the proof in an HTTP/2 frame. During BA, the HTTP WG expressed

Re: [TLS] RFC 7924 on Transport Layer Security (TLS) Cached Information Extension

2016-07-21 Thread Sean Turner
Congrats to all involved! spt > On Jul 19, 2016, at 10:01, rfc-edi...@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > >RFC 7924 > >Title: Transport Layer Security (TLS) Cached >Information Extension

Re: [TLS] Resumption Contexts and 0-RTT Finished

2016-07-21 Thread Ilari Liusvaara
On Wed, Jul 20, 2016 at 01:42:58AM -0400, Hugo Krawczyk wrote: > Without taking a position on the implementation issues, I am in favor of > Option A with a dedicated context value (and an explicit name "PSK > Context") as this makes clear the function of this value. Relying in > Finished makes it