On Mon, Oct 10, 2016 at 11:27 PM, Martin Thomson
wrote:
> On 11 October 2016 at 07:57, Kyle Rose wrote:
>> FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin
>> that the web is substantially broken without retry logic in the
On Wed, Oct 12, 2016 at 12:55 PM, Kyle Rose wrote:
> On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara > wrote:
>
>> > There's my confusion. I misinterpreted both the Zero-RTT diagram and the
>> > table of handshake contexts under "Authentication
On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara
wrote:
> > There's my confusion. I misinterpreted both the Zero-RTT diagram and the
> > table of handshake contexts under "Authentication Messages", specifically
> > "ClientHello ... later of
On Wed, Oct 12, 2016 at 01:51:25PM -0400, Kyle Rose wrote:
> On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara
> wrote:
>
> > > By this point in the connection, there is proof that early_data has not
> > > been replayed. The application doesn't necessarily know this when
On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara
wrote:
> > By this point in the connection, there is proof that early_data has not
> > been replayed. The application doesn't necessarily know this when the
> early
> > data is first delivered, but it can find out later,
On Wed, Oct 12, 2016 at 11:54:59AM -0400, Kyle Rose wrote:
> On Wed, Oct 12, 2016 at 4:11 AM, Ilari Liusvaara
> wrote:
>
> Ok, I see where you're going with this. I'm not sure whether I would put
> the ALP filtering logic in the API or do something more like:
>
>
On Wed, Oct 12, 2016 at 4:11 AM, Ilari Liusvaara
wrote:
> For when 0-RTT has become boring enough for me to implement, I would
> think the server-side interface I put in would be something like the
> following:
>
> - ServerSession::getReplayable0RttReader(alp_list) ->
On Tue, Oct 11, 2016 at 09:41:55PM -0400, Kyle Rose wrote:
> >
> > The 0-RTT API in NSS allows a server to detect this transition. The
> > problem that I think David was referring to is that the specific
> > instant of the transition is lost when the multiple layers of stack
> > that sit on top
On 11 October 2016 at 07:57, Kyle Rose wrote:
> FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin
> that the web is substantially broken without retry logic in the browsers,
> that naturally make application-level replay mitigation a necessity. But I
>
On Mon, Oct 10, 2016 at 1:49 PM, Watson Ladd wrote:
>
> The problem is with poorly-behaved senders and attackers resending
> 0-RTT data. Receivers should be able to ensure side-effectfull
> operations are not carried out by 0-RTT data. Making 0-RTT silent in
> APIs
On Sat, Oct 8, 2016 at 10:32 AM, David Benjamin wrote:
> To add to that, in out-of-order transports, whether a message was sent over
> 0-RTT or not may not even be very well-defined. If QUIC originally sent data
> over 0-RTT but had to retransmit it after the full
To add to that, in out-of-order transports, whether a message was sent over
0-RTT or not may not even be very well-defined. If QUIC originally sent
data over 0-RTT but had to retransmit it after the full connection
parameters are available, I believe it will use those.
Even in an in-order
On Sat, Oct 8, 2016 at 10:06 AM, Ilari Liusvaara
wrote:
> On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote:
> >
> > In the APIs people have been designing, 0-RTT can become 1-RTT but not
> the
> > other way around.
> > Specifically:
> >
> > - There is an
On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote:
>
> In the APIs people have been designing, 0-RTT can become 1-RTT but not the
> other way around.
> Specifically:
>
> - There is an option to allow 0-RTT writing
> - With that option on, SSL_Write() succeeds in both 0-RTT and 1-RTT
On Sat, Oct 8, 2016 at 7:25 AM, Watson Ladd wrote:
> On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla wrote:
> >
> >
> > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >>
> >> On Fri, Oct 07, 2016 at 01:41:14PM
On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla wrote:
>
>
> On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara
> wrote:
>>
>> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
>> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
>> >
On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara
wrote:
> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
> > wrote:
> > >
> > > Also, it is very likely that 0-RTT would need
On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
> On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
> wrote:
> >
> > Also, it is very likely that 0-RTT would need its own read API, because
> > it is pretty unlikely that existing API could be safely
On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
wrote:
> On Fri, Sep 23, 2016 at 04:08:38PM -0700, Watson Ladd wrote:
>> Dear all,
>> We've got API guidance and application layer interactions on the TODO
>> list, and both of these are important and don't show up yet. I
On Fri, Sep 23, 2016 at 04:08:38PM -0700, Watson Ladd wrote:
> Dear all,
> We've got API guidance and application layer interactions on the TODO
> list, and both of these are important and don't show up yet. I can't
> credibly commit to taking a big stab at them, but hopefully this email
> is
Dear all,
We've got API guidance and application layer interactions on the TODO
list, and both of these are important and don't show up yet. I can't
credibly commit to taking a big stab at them, but hopefully this email
is detailed enough that it serves as a starting point.
The problems with the
21 matches
Mail list logo