Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

Hi, > On 2 Mar 2018, at 08:32, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > >> On Thu, 2018-03-01 at 21:52 +0000, Paterson, Kenny wrote: >> Hi, >> >> I've been analysing the record protocol spec for TLS 1.3 a bit, >> specifically the new pad

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

Hi Ekr. Ah that's great, thanks - and I think the text in the Appendix already addresses the issues very well. Sorry for the bandwidth consumption. Cheers, Kenny -Original Message- From: Eric Rescorla <e...@rtfm.com> Date: Thursday, 1 March 2018 at 22:27 To: "Pate

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

Hi, I've been analysing the record protocol spec for TLS 1.3 a bit, specifically the new padding mechanism. I think there's a possible timing attack on a naïve implementation of de-padding. Maybe this is already known to people who've been paying more attention than me! Recall that the

[TLS] Possible timing

___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

Hi, On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)" wrote: >From: Aaron Zauner >Date: Wednesday, March 1, 2017 at 9:24 AM >To: 'Quynh' >Cc: Sean Turner , ""

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

Hi Quynh, I'm meant to be on vacation, but I'm finding this on-going discussion fascinating, so I'm chipping in again. On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) > wrote: Hi Atul, I hope you had a happy Valentine! From: Atul Luykx

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

Hi, On 10/02/2017 18:56, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote: >Dear Kenny, > >From: "Paterson, Kenny" <kenny.pater...@rhul.ac.uk> >Date: Friday, February 10, 2017 at 12:22 PM >To: 'Quynh' <quynh.d...@nist.gov>, Sean Turner &

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

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

Re: [TLS] Industry Concerns about TLS 1.3

Hi Andrew, My view concerning your request: no. Rationale: We're trying to build a more secure internet. Meta-level comment: You're a bit late to the party. We're metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans. More exactly, we

Re: [TLS] Randomization of nonces

Sadly, you can't implement XGCM using an existing AES-GCM API, because of the way the MAC (which is keyed) is computed over the ciphertext in the standard GCM scheme. This does not contradict what you wrote, but may be a barrier to adoption. Cheers Kenny On 15 Aug 2016, at 16:40, Watson Ladd

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi On 13/07/2016 11:55, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote: >Good morning Kenny, > >On 7/12/16, 3:03 PM, "Paterson, Kenny" <kenny.pater...@rhul.ac.uk> wrote: > >>Hi, >>Could you define "safe", please? Safe f

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

-Original Message----- >> From: Paterson, Kenny [mailto:kenny.pater...@rhul.ac.uk] >> Sent: Tuesday, July 12, 2016 1:17 PM >> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; tls@ietf.org >> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >> &

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi On 12/07/2016 18:12, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote: >Hi Kenny, > >On 7/12/16, 1:05 PM, "Paterson, Kenny" <kenny.pater...@rhul.ac.uk> wrote: > >>Hi >> >>On 12/07/2016 16:12, "Dang, Quynh (Fed)" <

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi On 12/07/2016 18:04, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote: >Hi Kenny, > >On 7/12/16, 12:33 PM, "Paterson, Kenny" <kenny.pater...@rhul.ac.uk> wrote: > >>Finally, you write "to come to the 2^38 record limit, they assume that &g

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Dang, Quynh (Fed) >> Sent: Tuesday, July 12, 2016 11:12 AM >> To: Paterson, Kenny; Dang, Quynh (Fed); Eric Rescorla; tls@ietf.org >> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >> >> Hi Kenny, >> >> The indistinguishability-based security no

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi Quynh, This indistinguishability-based security notion is the confidentiality notion that is by now generally accepted in the crypto community. Meeting it is sufficient to guarantee security against many other forms of attack on confidentiality, which is one of the main reasons we use it. You

Re: [TLS] Consensus call for keys used in handshake and data messages

Hi Ilari, On 14/06/2016 20:01, "TLS on behalf of Ilari Liusvaara" wrote: >I too haven't seen an argument (or am I able to construct one >myself) on why using the same key causes more issues than >"more difficult for cryptographers"

Re: [TLS] Consensus call for keys used in handshake and data messages

Hi Ilari, On 15/06/2016 17:23, "TLS on behalf of Ilari Liusvaara" wrote: >On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: >> >> To be clear, we're being asked

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

Hi On 16/05/2016 11:15, "Aaron Zauner" <a...@azet.org> wrote: >Hi Kenny, > >> On 16 May 2016, at 16:48, Paterson, Kenny <kenny.pater...@rhul.ac.uk> >>wrote: >> >> Maybe the confusion is this: in your authenticity attack, you do reco

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

Hi On 16/05/2016 10:37, "Aaron Zauner" <a...@azet.org> wrote: >Hi Kenny, > >> On 16 May 2016, at 16:18, Paterson, Kenny <kenny.pater...@rhul.ac.uk> >>wrote: >> >> Hi Aaron, >> >> If AES-GCM ever generates two ciphertexts using

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

Hi Aaron, If AES-GCM ever generates two ciphertexts using the same key and the same 96-bit nonce, then the underlying CTR-mode keystreams will be the same. XORing the ciphertexts together then produces the XOR of the plaintexts, from which the two individual plaintexts can be recovered (usually)

Re: [TLS] Include Speck block cipher?

Hi I think Rich Salz already said exactly what CFRG would say: > If someone wants to see SPECK adopted by IETF protocols, the first thing >that will have to happen is papers analyzing it. There's some analysis already, but not that much. Regards, Kenny On 21/03/2016 14:27, "TLS on behalf

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hi On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" wrote: >On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann > wrote: >> After a number of, uh, gentle reminders from people who have been >>waiting for >> this,

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hi On 16/03/2016 18:44, "Watson Ladd" <watsonbl...@gmail.com> wrote: >On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny ><kenny.pater...@rhul.ac.uk> wrote: >> Hi >> >> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" >><

Re: [TLS] Proposal: don't change keys between handshake and application layer

Hi My 2c below... On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet" wrote: > > >Besides, in our analysis of the handshake, we get precisely the same >“fresh, never-used secret” property you are advocating, with or > without the

Re: [TLS] Data volume limits

RC4 does not rekey per application layer fragment in TLS. The same key is used for the duration of a connection. Other protocols using RC4 do rekey per packet, eg WEP and WPA/TKIP. Cheers Kenny > On 16 Dec 2015, at 16:37, Ryan Carboni wrote: > > How often does TLS rekey