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" has
> recipient identity c
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 +, David Benjamin wrote:
> > > > O
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 <
> > martin.thom...@gmail.com>
> >
> > I don't th
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 simplification. In my
> >
No plans to implement client auth in 0-th RTT.
Cheers,
Andrei
From: Yoav Nir [mailto:ynir.i...@gmail.com]
Sent: Wednesday, January 27, 2016 11:10 AM
To: Andrei Popov
Cc: Bill Cox ; Martin Thomson
; tls@ietf.org
Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished
On 27 Jan
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
> > don't see it being commonp
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 CertificateRequest (a
> > combination that's possible w
> 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 traditional
> proof-of-posse
AM
To: Martin Thomson
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
mailto:martin.thom...@gmail.com>> wrote:
I get your point, but I don't see that as a simplification. In my
mind, post-handshake clien
> 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 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 includes actions (especially non-idempotent ones)
> tha
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 correct, then you get
aut
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. Or, I
>> don't see it being commonplace.
>
>
> The
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 CertificateRequest (a
> combination that's possible with or without my restriction) and the other is
> a brand new han
On Tue, Jan 26, 2016 at 9:11 PM Martin Thomson
wrote:
> 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 altog
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
> useless because the first
On Tue, Jan 26, 2016 at 8:28 PM Martin Thomson
wrote:
> This is in part why I created:
> https://github.com/tlswg/tls13-spec/pull/402
Ah, great. And indeed there is a paragraph I missed:
"""
At this point, the handshake is complete, and the client and server may
exchange application layer data.
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
18 matches
Mail list logo
