On Mon, Jul 4, 2016 at 5:51 AM, Ilari Liusvaara
wrote:
> On Sun, Jul 03, 2016 at 06:00:25PM -0700, Eric Rescorla wrote:
> > I believe that this is the right design.
> >
> > The primary proposed use for EncryptedExtensions in the 0-RTT flight is
> for
> > EncryptedSNI. However, I don't believe tha
On Sun, Jul 03, 2016 at 06:00:25PM -0700, Eric Rescorla wrote:
> I believe that this is the right design.
>
> The primary proposed use for EncryptedExtensions in the 0-RTT flight is for
> EncryptedSNI. However, I don't believe that they are actually that useful in
> this case because the design co
I believe that this is the right design.
The primary proposed use for EncryptedExtensions in the 0-RTT flight is for
EncryptedSNI. However, I don't believe that they are actually that useful in
this case because the design constraints for EncryptedSNI are intended to
allow the client to encrypt th
On 27 June 2016 at 02:34, Ilari Liusvaara wrote:
> That's the reason it is XOR'd currently, but the XOR probably will
> be changed to ADD32 to break correlation-to-parent (which is really
> nasty privacy-wise) in case of ticket reuse.
Let's not make that probably. I've updated the PR.
_
On Sun, Jun 26, 2016 at 05:34:04AM +, Subodh Iyengar wrote:
> Was there a compelling reason to not just put the ticket age in the
> clear in the CHLO field as @davidben alluded to before. It seems to
> make it much simpler in general.
Unfortunately, just putting it in plain allows correlating
Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT
On 24 June 2016 at 01:05, David Benjamin wrote:
> I don't think this matters. Just don't reuse tickets. But, if we cared, per
> the "dumbest possible thing that might work" school of thought, we can
> replace
On 24 June 2016 at 01:05, David Benjamin wrote:
> I don't think this matters. Just don't reuse tickets. But, if we cared, per
> the "dumbest possible thing that might work" school of thought, we can
> replace XOR with addition modulo 2^32. Now ticket reuse leaks the delta
> between two ClientHello
On Thu, Jun 23, 2016 at 6:35 AM David Benjamin
wrote:
> On Thu, Jun 23, 2016 at 6:35 AM Ilari Liusvaara
> wrote:
>
>> On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote:
>> > When implementing 0-RTT, an in particular the ticket_age extension, we
>> > discovered that this greatly incr
On Thu, Jun 23, 2016 at 6:35 AM Ilari Liusvaara
wrote:
> On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote:
> > When implementing 0-RTT, an in particular the ticket_age extension, we
> > discovered that this greatly increases the complexity of the server
> > state machine.
> >
> > Da
On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote:
> When implementing 0-RTT, an in particular the ticket_age extension, we
> discovered that this greatly increases the complexity of the server
> state machine.
>
> David Benjamin rather flippantly described a solution to this problem
When implementing 0-RTT, an in particular the ticket_age extension, we
discovered that this greatly increases the complexity of the server
state machine. The problem is that the server is making decisions
about what to send in the ServerHello based on the content of messages
that appear after the
11 matches
Mail list logo