On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara
wrote:
> On Thu, Jan 28, 2016 at 05:36:22PM +, David Benjamin wrote:
> > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Wed, Jan 27, 2016 at 07:28:47PM +,
On Fri, Jan 29, 2016 at 07:55:53PM +, David Benjamin wrote:
> On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara
> wrote:
>
> Perhaps I misunderstood you. I read "dynamic reauth" in your message above
> as the post-handshake auth mechanism. You said that "server 0-RTT"
On Thu, Jan 28, 2016 at 05:36:22PM +, David Benjamin wrote:
> On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara
> wrote:
>
> > On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote:
> > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <
> >
On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara
wrote:
> On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote:
> > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <
> martin.thom...@gmail.com>
> > wrote:
> > >
> > > I get your point, but I don't see that as a
On Jan 27, 2016 9:45 AM, "Martin Thomson" wrote:
>
> On 28 January 2016 at 02:09, Watson Ladd wrote:
> > All 0-RTT data is replayable, but I don't see what replaying a
> > authenticated replayable connection gets you.
>
> If the 0-RTT flight
> e.g., "please pay Watson $10, my certificate authenticates this request"
We already know non-idempotent actions cannot be put into 0 RTT.
s/cannot/should not/ This might help prevent problems. Might. I don't know
if it's worth it.
___
TLS mailing
On 28 January 2016 at 02:09, Watson Ladd wrote:
> All 0-RTT data is replayable, but I don't see what replaying a
> authenticated replayable connection gets you.
If the 0-RTT flight includes actions (especially non-idempotent ones)
that only apply if the authentication is
To: Martin Thomson <martin.thom...@gmail.com>
Cc: tls@ietf.org
Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished
On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson
<martin.thom...@gmail.com<mailto:martin.thom...@gmail.com>> wrote:
I get your poin
> On 27 Jan 2016, at 8:38 PM, Andrei Popov wrote:
>
> Ø The CertificateVerify message is still listed as an option in the 0-RTT
> client's first flight at t = 0. Is this a mistake? I have not heard that
> anyone wants to do this, as there is no possibility of a
On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson
wrote:
> On 27 January 2016 at 14:11, David Benjamin wrote:
> > Why do you say it's an optimization? They're exactly the same except the
> > simplified one reduces to normal 0-RTT + mid-stream
>; tls@ietf.org
Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished
On 27 Jan 2016, at 8:38 PM, Andrei Popov
<andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote:
> The CertificateVerify message is still listed as an option in the 0-RTT
On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote:
> On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson
> wrote:
> >
> > I get your point, but I don't see that as a simplification. In my
> > mind, post-handshake client authentication doesn't happen. Or, I
> >
On Wed, Jan 27, 2016 at 6:12 AM, Bill Cox wrote:
> On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson
> wrote:
>>
>>
>> I get your point, but I don't see that as a simplification. In my
>> mind, post-handshake client authentication doesn't happen.
This is in part why I created: https://github.com/tlswg/tls13-spec/pull/402
My understanding is that the server is able to send any data that does
not depend on client authentication at t=0.5 and any data that depends
on client authentication at either t=0.5 if it successfully consumes
the client
On 27 January 2016 at 12:58, David Benjamin wrote:
> If the server needs to send a CertificateRequest (i.e. the client
> mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a
> 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but
>
15 matches
Mail list logo