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
Ø 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-possession in the first flight.
I agree with this: client auth in 0-
> 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 1/27/16, 12:47 , "Martin Thomson" wrote:
>On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL
> wrote:
>> Anon != Ephemeral, despite some similarities.
>
>From a protocol perspective, they are the same.
If you mean that you cannot distinguish between the two on the wire - I
agree.
On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL
wrote:
> Anon != Ephemeral, despite some similarities.
>From a protocol perspective, they are the same. The distinction at
the protocol level between ECDH_RSA (for example) and ECDH_anon is
that ECDH_anon requires a ServerKeyShare mes
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
IMHO it's not a good idea to re-purpose existing cipher-suites and alter their
observed behavior. Likewise for the name overloading.
Anon != Ephemeral, despite some similarities.
My apologies if I'm missing the point or the frame of a larger issue.
Sent from my BlackBerry 10 smartphone on t
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
AVTCORE and TLS,
TLS WG, you are included in this WG last call, as this document affects
the TLS ContentType IANA registry.
This email starts a two week WG last call, that ends on the 10th of
February. The intended status of this document is standards track
(Proposed Standard).
The documen
On Wed, 2016-01-27 at 14:51 +1100, Martin Thomson wrote:
> 4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon
> cipher suites.
>
> I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17
My understanding of DH_anon and ECDH_anon is that they were made to be
used with sta
14 matches
Mail list logo