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

All, Thank you for your input on this errata report and apologies for the delayed reply. We have updated as requested. As this thread involved a number of responses, please review the text as it currently appears at http://www.rfc-editor.org/errata_search.php?rfc=5288=4694 and let us know

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

> On 14 Jun 2016, at 19:25, Joseph Lorenzo Hall wrote: > > s/it's/its/ in one place in your errata text, Aaron. Thank you. I suggest the RFC Errata editors change text and further additions/recommendations by others along the way when publishing (if that's the right way to

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

s/it's/its/ in one place in your errata text, Aaron. On Tue, Jun 14, 2016 at 5:04 AM, Aaron Zauner wrote: > Hi, > > It's been a few weeks. We by now know of at least one other affected vendor. > I think this errata is valid and should be accepted. I'll take any feedback > and

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

Hi, > The first step of our attack involves attacker controlled content. So yes > (phishing, unauthenticated HTTP, selective company DPI etc.). In our example > we use a local proxy to carry out the attack. I hope I can post a full > version of the actual paper and PoC to this thread soon.

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

Hi Kenny, > On 16 May 2016, at 17:24, Paterson, Kenny wrote: > > Good to get this cleared up. Yes, it's eminently practical to recover the > two plaintexts from their XOR assuming you have a good language model > (e.g. one can use a Markov model with a suitable memory

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

Hi On 16/05/2016 11:15, "Aaron Zauner" wrote: >Hi Kenny, > >> On 16 May 2016, at 16:48, Paterson, Kenny >>wrote: >> >> Maybe the confusion is this: in your authenticity attack, you do recover >> the GHASH key, and the effect is catastrophic. In the

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

Hi Kenny, > On 16 May 2016, at 16:48, Paterson, Kenny wrote: > > Maybe the confusion is this: in your authenticity attack, you do recover > the GHASH key, and the effect is catastrophic. In the confidentiality > attack, one can recover plaintexts for the records with

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

Hi On 16/05/2016 10:37, "Aaron Zauner" wrote: >Hi Kenny, > >> On 16 May 2016, at 16:18, Paterson, Kenny >>wrote: >> >> Hi Aaron, >> >> If AES-GCM ever generates two ciphertexts using the same key and the >>same >> 96-bit nonce, then the underlying

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

Hi Kenny, > On 16 May 2016, at 16:18, Paterson, Kenny wrote: > > 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

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] [Technical Errata Reported] RFC5288 (4694)

Hi, In the TLS case, RFC5288 defines the following IV construction (Section 3): ``` struct { opaque salt[4]; opaque nonce_explicit[8]; } GCMNonce; The salt is the "implicit" part of the nonce and is not sent in the packet.

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

> On 16 May 2016, at 6:50 AM, Atul Luykx wrote: > > Here's a possible re-write of the second paragraph: > > Nonce re-use in AES-GCM results in failure of both confidentiality and > authenticity. Not only will confidentiality be breached by leaking the XOR of >

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

Atul Luykx writes: >Here's a possible re-write of the second paragraph: That looks good. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

Here's a possible re-write of the second paragraph: Nonce re-use in AES-GCM results in failure of both confidentiality and authenticity. Not only will confidentiality be breached by leaking the XOR of any two packets processed under the same nonce, but TLS sessions can also be attacked

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

Aaron Zauner writes: >If so, could you suggest better wording for this specific paragraph? I would just leave it as "nonce", with no attempt at a definition. If there are any cryptographers who don't know what a nonce is they can look it up. If they use an authoritative source

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

The way I read the first draft, the wording made it sound like "nonce" was a contraction of the words "(N)umber used (once)". I thought I learned something. Then I looked it up, and unfortunately, that is not the case, as cute as it would be. That is the problem with the wording. Even if a nonce

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

On Sun, May 15, 2016 at 11:43 AM, Rick van Rein wrote: > Hi, > > > I think the erratum needs an erratum. Firstly, "nonce" doesn't mean > "number > > used once", and secondly nonce re-use in AES-GCM doesn't just result in > > "catastrophic failure of it's authenticity", it

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

On Sun, May 15, 2016 at 6:50 AM, Aaron Zauner wrote: > I know that the word "nonce" does have another meaning as well (BTW I'm > not a native english speaker, as you may have guessed). But do you think > that is really relevant in this case? If so, could you suggest better >

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

On Sun, May 15, 2016 at 3:52 PM, Peter Gutmann wrote: > Aaron Zauner writes: > > >What do you think nonce stands for? > >https://en.wikipedia.org/wiki/Cryptographic_nonce > > Well there's your first mistake, you're using Wikipedia as a reference. >

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

Hi, On May 15, 2016 10:28, "Peter Gutmann" wrote: > > RFC Errata System writes: > > >The following errata report has been submitted for RFC5288, "AES Galois > >Counter Mode (GCM) Cipher Suites for TLS". > > I think the erratum needs an

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

Aaron Zauner writes: >What do you think nonce stands for? >https://en.wikipedia.org/wiki/Cryptographic_nonce Well there's your first mistake, you're using Wikipedia as a reference. "nonce" is from medieval English, and predates modern cryptography and IVs by about 800 years. >In

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

Hi, > I think the erratum needs an erratum. Firstly, "nonce" doesn't mean "number > used once", and secondly nonce re-use in AES-GCM doesn't just result in > "catastrophic failure of it's authenticity", it results in catastrophic > failure of the entire mode, both confidentiality and

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

RFC Errata System writes: >The following errata report has been submitted for RFC5288, "AES Galois >Counter Mode (GCM) Cipher Suites for TLS". I think the erratum needs an erratum. Firstly, "nonce" doesn't mean "number used once", and secondly nonce re-use in AES-GCM

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

The following errata report has been submitted for RFC5288, "AES Galois Counter Mode (GCM) Cipher Suites for TLS". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5288=4694 -- Type: