Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Ryan Hamilton
On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson wrote: > David Benjamin wrote our section on 0-RTT backward compatibility to be > a little bit lenient about server deployment. On consideration, I > think that a simpler set of rules are better: > > 1. If the server advertises support for 0-RTT, t

Re: [TLS] Consensus call for keys used in handshake and data messages

2016-06-21 Thread Ilari Liusvaara
On Mon, Jun 20, 2016 at 11:43:41PM -0400, Dave Garrett wrote: > > An idea for an option 4: Keep typing and keying as it currently is > (as of draft 13), but mandate a KeyUpdate immediately following > (and/or before) non-application traffic. We already have a mechanism > to use different keys in s

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Ilari Liusvaara
On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson > wrote: > > > David Benjamin wrote our section on 0-RTT backward compatibility to be > > a little bit lenient about server deployment. On consideration, I > > think that a simpler se

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread David Benjamin
On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara wrote: > On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: > > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson < > martin.thom...@gmail.com> > > wrote: > > > > > David Benjamin wrote our section on 0-RTT backward compatibility to be > >

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Martin Thomson
To be clear about this, I expect that browsers will do some fairly horrific things in response to this. We will attempt to use 0-RTT, get TLS 1.2 and abort as described. But then we will do the shameful thing and fall back to 1.2. Plotting out the alternatives, I don't really see a better option

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Watson Ladd
On Jun 21, 2016 5:25 PM, "Martin Thomson" wrote: > > To be clear about this, I expect that browsers will do some fairly > horrific things in response to this. We will attempt to use 0-RTT, > get TLS 1.2 and abort as described. Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a refusal? >

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Bill Frantz
On 6/22/16 at 5:24 PM, martin.thom...@gmail.com (Martin Thomson) wrote: To be clear about this, I expect that browsers will do some fairly horrific things in response to this. We will attempt to use 0-RTT, get TLS 1.2 and abort as described. But then we will do the shameful thing and fall back

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Martin Thomson
On 22 June 2016 at 10:27, Watson Ladd wrote: > Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a refusal? The problem isn't that you get a 1.2 ServerHello, it's what happens after that. The server is going to choke on your 0-RTT data when it receives that instead of the client's second f

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Martin Thomson
On 22 June 2016 at 10:30, Bill Frantz wrote: > Well, it seems like a browser could try TLS 1.3 without 0-RTT first. > > If it connects with 1.3 non-0-RTT, then it could mark the host as not > supporting 0-RTT for a day or so and after that time retry to see if the > host has been fixed. Yes, that

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Watson Ladd
On Jun 21, 2016 5:44 PM, "Martin Thomson" wrote: > > On 22 June 2016 at 10:27, Watson Ladd wrote: > > Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a refusal? > > The problem isn't that you get a 1.2 ServerHello, it's what happens > after that. The server is going to choke on your 0-RT

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread David Benjamin
On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson wrote: > On 22 June 2016 at 10:30, Bill Frantz wrote: > > Well, it seems like a browser could try TLS 1.3 without 0-RTT first. > > > > If it connects with 1.3 non-0-RTT, then it could mark the host as not > > supporting 0-RTT for a day or so and aft

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Martin Thomson
I've added this option to my PR. I've also weakened the deployment requirement to a SHOULD in light of that. I'll learn to live with the bad taste that leaves :) On 22 June 2016 at 12:31, David Benjamin wrote: > On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson > wrote: >> >> On 22 June 2016 at 1

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread Martin Thomson
On 22 June 2016 at 12:01, Watson Ladd wrote: > Why isn't 0-RTT an extension in the Client Hello to deal with this? You can't stream extensions, which unfortunately is required given how most software interacts with their TLS stack. Let's be clear, the actual risk we're talking about is pretty-mu