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
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
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
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
> >
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
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?
>
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
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
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
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
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
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
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
13 matches
Mail list logo
