On Tue, Jun 28, 2016 at 07:01:51PM +0200, Hubert Kario wrote:
> On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote:
> >
> > Sticking 0-RTT data into ClientHello also has the following problems:
> > - One needs to mangle ClientHello (strip an extension on receiver side)
> > to obtain hash su
On Tuesday 28 June 2016 17:40:45 David Benjamin wrote:
> On Tue, Jun 28, 2016 at 1:02 PM Hubert Kario wrote:
>
> > On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote:
> > > On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote:
> > > > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson
>
On Tue, Jun 28, 2016 at 1:02 PM Hubert Kario wrote:
> On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote:
> > On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote:
> > > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson
> > > wrote:
> > > > On 22 June 2016 at 12:01, Watson Ladd wrote:
On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote:
> On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote:
> > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson
> > wrote:
> > > On 22 June 2016 at 12:01, Watson Ladd wrote:
> > >> Why isn't 0-RTT an extension in the Client Hello to deal
There are also very common cases of using multiple CDNs or server farms
with different capabilities but with the same host name, or of switching a
live site between platforms. As others have mentioned, the behaviors need
to be well defined and result in extra rtt rather than hard failure to
allow 0
On 24 June 2016 at 00:26, Watson Ladd wrote:
> If we're
> willing to change the interaction pattern to support that, we can
> accommodate using 0RTT as an extension by gathering it all and sending
> when the handshake happens.
That's a very different constraint on the usage. In one, you have to
On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote:
> On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson
> wrote:
> > 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 unfortunatel
On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson
wrote:
> 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.
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
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 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
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 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 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 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 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?
>
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 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
> >
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 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
20 matches
Mail list logo
