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 browsers,
>> that naturally make application-lev
On Wed, Oct 12, 2016 at 3:57 PM, Eric Rescorla wrote:
> The 0-RTT traffic key incorporates the ClientHello.Random which is tied
> into the full handshake.
>
Ok, so for the replayed early data to be accepted, an adversary would also
have to swap out CH.Random and the (Finished) message, which wou
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 Messages",
>> specifically
>> > "ClientHello ... l
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 EncryptedExtensions/CertificateRequest". I'm
> > guessin
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 the
> > early
> > > data i
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, which may be all that
> > s
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:
>
> early_data = get_early_data()
>
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) -> ZRttReader
> - ZRttReader::g
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 of
>
> 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 of TLS get involved.
>
To David's second paragraph, if we eventually a
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
> don't think (nor do
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 transforms an interoperability
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 connection parameters are
> avail
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 transpor
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 option to allow 0-RTT writing
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 mo
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 -0700, Watson Ladd wrote:
> >> > On Fri, Sep
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
>> > wrote:
>> > >
>> > > Also, it is very likely that 0-R
On Fri, Oct 07, 2016 at 03:04:14PM -0700, 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
> > > wrote:
> > > >
> > > > Also, it is very likel
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 its own read API, because
> > > it is pretty unlikely t
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 retrofitted
> > or even purpose-buil
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 can't
>> credibly commit t
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 detai
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 a
24 matches
Mail list logo
