On 1 April 2016 at 03:46, Ilari Liusvaara wrote:
>
>> > I believe Option #2 is simplest.
>>
>> I didn't mention this because I was composing on a phone at the time,
>> but we have to decide whether to allow a second attempt at 0-RTT. If
>> we do, then the effect is a two round trip setback. I th
On Thu, Mar 31, 2016 at 12:18:45PM +1100, Martin Thomson wrote:
> On 31 March 2016 at 09:59, Eric Rescorla wrote:
> >> Option 2 suits best if we consider HelloRetryRequest to be a DoS feature
> >> exclusively or at least primarily. But we have other reasons for it and I
> >> don't think that DoS m
On 31 March 2016 at 16:09, Ilari Liusvaara wrote:
>> I think that option 1 is easy enough, since both sides have to extend the
>> hash in any case. 3 is just complexity.
>
> Yeah, I agree 3 is just complexity. Except I disagree that currently
> option 1 is easy enough, since the hash going to crea
On Thu, Mar 31, 2016 at 09:57:51AM +1100, Martin Thomson wrote:
> On 31 Mar 2016 5:56 AM, "Ilari Liusvaara" wrote:
> > Then on topic of 0-RTT, how does 0-RTT key hashes behave if
> > handshake is restarted (main handshake hash continues, but
> > 0-RTT hash context currently needs to be separate fr
On 31 March 2016 at 09:59, Eric Rescorla wrote:
>> Option 2 suits best if we consider HelloRetryRequest to be a DoS feature
>> exclusively or at least primarily. But we have other reasons for it and I
>> don't think that DoS mitigation is a big factor for TCP.
>
>
> I believe Option #2 is simplest
On Wed, Mar 30, 2016 at 3:57 PM, Martin Thomson
wrote:
> On 31 Mar 2016 5:56 AM, "Ilari Liusvaara"
> wrote:
> > Then on topic of 0-RTT, how does 0-RTT key hashes behave if
> > handshake is restarted (main handshake hash continues, but
> > 0-RTT hash context currently needs to be separate from th
