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
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
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
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
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?
> >
>
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
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
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
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
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
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
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
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
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, then it implies a
commitment to support TLS 1.3 for the duration
14 matches
Mail list logo