Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

What about Eric’s other point: Ø I am not sure that the regular TLS handshake guarantees these Ø properties either. The reason is that the server is permitted to Ø send data prior to receiving the client's second flight (0.5 RTT Ø data). With the server sending data prior to receiving the

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On Fri, Feb 10, 2017 at 12:44 PM, Victor Vasiliev wrote: > On Fri, Feb 10, 2017 at 3:39 PM, Eric Rescorla wrote: > >> I agree that the specification doesn't explicitly say this, but >> it's implicit in the processing rules via the following: >> > > We do at least explicitly promise those propert

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On Fri, Feb 10, 2017 at 12:52 PM, Sam Scott wrote: > Hi Ekr, > > That's a good summary of the situation. Indeed we weren't previously > considering TLS as able to enforce the ordering of messages which does seem > to mitigate our scenario for property A. We haven't really had a chance to > take t

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Hi Ekr, That's a good summary of the situation. Indeed we weren't previously considering TLS as able to enforce the ordering of messages which does seem to mitigate our scenario for property A. We haven't really had a chance to take that into consideration for property B, but at a glance it d

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Cas, Sam, I thought I understood your concern here but maybe I don't. Say we have the following sequence of messages 1. C->S: ClientHello 2. S->C: ServerHello...ServerFinished 3. C->S: ClientFinished 4. C->S: App message 5. S->C: App message 6. S->C: CertificateRequest 7: C->S: Cer

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Hi all, Thanks Ilari and Andrei for pointing towards the fact that TLS guarantees ordering of messages. On closer inspection, this has a similar effect as our partial fix to ensure the server must process the authentication message before continuing. We still consider the lack of a strict b

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Hi Sam, This part is not clear to me: > ...while in the post-handshake client auth, an attacker can decide this (by > dropping the message). How does the attacker drop a TLS-protected message without terminating the connection? Thanks, Andrei -Original Message- From: TLS [mailto:tls-

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Hi Ilari, Thanks for the comments. Assuming the client sends a valid certificate that the server accepts, then the server cannot finish the handshake or begin processing incoming application data until authenticating the client. This *almost* gives us property (A). In practice, the client is

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Rene, I care about side channel attacks in general as much as you do. But my question was that how you carry out those attacks on GCM in TLS 1.3's servers and clients ? Do those side-channel attacks apply only to GCM in TLS 1.3 ? Quynh. From: Rene Struik

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi, On 10/02/2017 18:56, "Dang, Quynh (Fed)" wrote: >Dear Kenny, > >From: "Paterson, Kenny" >Date: Friday, February 10, 2017 at 12:22 PM >To: 'Quynh' , Sean Turner >Cc: IRTF CFRG , "" >Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs >(#765/#769) > > > >>Dear Quynh, >>

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Quynh: Not sure where to start (there is vast literature on side channel attacks and other implementation attacks). A good starting point would be the book [1], but one could also look at some NIST publications [2]. Side channel attacks differs from cryptanalytic attacks in that it does n

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Dear Kenny, From: "Paterson, Kenny" mailto:kenny.pater...@rhul.ac.uk>> Date: Friday, February 10, 2017 at 12:22 PM To: 'Quynh' mailto:quynh.d...@nist.gov>>, Sean Turner mailto:s...@sn3rd.com>> Cc: IRTF CFRG mailto:c...@irtf.org>>, "mailto:tls@ietf.org>>" mailto:tls@ietf.org>> Subject: Re: [TLS

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Rene, From: TLS mailto:tls-boun...@ietf.org>> on behalf of Rene Struik mailto:rstruik@gmail.com>> Date: Friday, February 10, 2017 at 10:51 AM To: Sean Turner mailto:s...@sn3rd.com>>, "mailto:tls@ietf.org>>" mailto:tls@ietf.org>> Cc: IRTF CFRG mailto:c...@irtf.org>> Subject: Re: [TLS] [Cfr

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Dear Quynh, On 10/02/2017 12:48, "Dang, Quynh (Fed)" wrote: >Hi Kenny, > >>Hi, >> >> >>My preference is to go with the existing text, option a). >> >> >>From the github discussion, I think option c) involves a less >>conservative >>security bound (success probability for IND-CPA attacker bounde

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On Fri, Feb 10, 2017 at 12:43:56PM +, Cas Cremers wrote: > Dear all, > > In the process of completing our Tamarin analysis of TLS 1.3 revision 18, > we hit upon some behaviour that may lead to applications making incorrect > assumptions. It is not an immediate attack, but we can imagine scenar

Re: [TLS] PR#875: Additional Derive-Secret Stage

Martin Thomson wrote: > This is a good idea. +1 > Just to highlight this point: if we need to add a PQ key exchange, > there is no guarantee that it will have exactly the same properties as > the key exchange methods we have today. I expect that need to arise > relatively soon, so that's an extr

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Dear colleagues: I would suggest adding the following paragraph at the end of Section 5.5: [current text of Section 5.5] There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys.[AEAD-LIMITS]

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Kenny, From: TLS mailto:tls-boun...@ietf.org>> on behalf of "Paterson, Kenny" mailto:kenny.pater...@rhul.ac.uk>> Date: Friday, February 10, 2017 at 4:06 AM To: Sean Turner mailto:s...@sn3rd.com>> Cc: IRTF CFRG mailto:c...@irtf.org>>, "mailto:tls@ietf.org>>" mailto:tls@ietf.org>> Subject: Re:

[TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Dear all, In the process of completing our Tamarin analysis of TLS 1.3 revision 18, we hit upon some behaviour that may lead to applications making incorrect assumptions. It is not an immediate attack, but we can imagine scenarios where it can cause problems. We describe it below, and show that it

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Sean and all, I agree with everyone that the text in (b) was not very good text. The problem with (c) is that it is not precise at places and it leaves out a lot of informative discussions which users should know. The sentence "The maximum amount of plaintext data that can be safely encry

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

On Fri, Feb 10, 2017 at 04:44:58PM +1100, Martin Thomson wrote: > On 10 February 2017 at 16:07, Sean Turner wrote: > > a) Close these two PRs and go with the existing text [0] > > b) Adopt PR#765 [1] > > c) Adopt PR#769 [2] > > > a) I'm happy enough with the current text (I've implemented that a

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi, My preference is to go with the existing text, option a). >From the github discussion, I think option c) involves a less conservative security bound (success probability for IND-CPA attacker bounded by 2^{-32} instead of 2^{-60}). I can live with that, but the WG should be aware of the weaker