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

[Megan Ferguson]

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 
if any further updates are necessary.

RFC Editor/mf


On Jun 15, 2016, at 4:11 AM, Aaron Zauner  wrote:

> 
>> 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 proceed, I'm quite unfamiliar with the errata process and 
> the information on it is a bit terse, to be honest).
> 
> Aaron

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

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

[Aaron Zauner]

> 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 proceed, I'm quite unfamiliar with the errata process and the 
information on it is a bit terse, to be honest).

Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Lorenzo Hall]

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 improvements if valid.
>
> Aaron
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

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

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

[Aaron Zauner]

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.

https://eprint.iacr.org/2016/475
https://github.com/nonce-disrespect/nonce-disrespect

(data-sets should be indexed by scans.io in a bit)

Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Aaron Zauner]

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 length; this would
> work for HTTP records, natural language, etc). To code it all up is not
> trivial - I currently set it as a final year project for our undergrad
> students, for example. The paper by Mason et al from CCS 2006 gives a nice
> account of the whole business.

Yes, we (I?) mixed up two different attack vectors.

I wasn't aware of the CCS 2006 paper, that was long before I got into TLS, to 
be honest. I'll certainly read up on it. It's a really nice undergrad project, 
I'm always happy to hear that universities do teach practical attacks, let 
their students write PoC for them etc., unfortunately I've seen quite the 
opposite on a lot of occasions and lecturers teaching on out-dated crypto 
protocols and primitives or trying to explain simple designs with very 
"esoteric" slide-decks.

Anyhow: what has been said in the thread already on the attack does of course 
make sense to me, but it isn't what I was referring to w.r.t. our attack 
contribution. So I think I'm to blame for the confusion here. I think both 
attacks are worth noting in the Errata as some implicitly already mentioned 
before. Does anyone disagree on that?

> OK, makes sense now.

Perfect :)

Thank you for the feedback,
Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Paterson, Kenny]

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 confidentiality
>> attack, one can recover plaintexts for the records with repeated nonces,
>> but not the encryption key. The effect may be bad - but it's perhaps not
>> as catastrophic in practice as the authenticity attack.
>
>Ah, I see. Yes and we do not consider this in our paper at all. Maybe we
>should? Not sure how practical this is.

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 length; this would
work for HTTP records, natural language, etc). To code it all up is not
trivial - I currently set it as a final year project for our undergrad
students, for example. The paper by Mason et al from CCS 2006 gives a nice
account of the whole business.

>
>> Think about it this way: for your injection attack, you need to recover
>> the CTR keystream - otherwise you couldn't properly AES-GCM-encrypt your
>> chosen plaintext record for the injection. But if you recovered the
>> keystream as part of your attack, then you've also recovered the
>>plaintext
>> for the original record.
>> 
>> Or maybe in your injection attack you were assuming you already *knew*
>>the
>> plaintext? That would make sense, I guess - a lot easier then to recover
>> the keystream than doing the "undoing the XOR" attack needed to recover
>> P_1 and P_2 from P_1 XOR P_2.
>
>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.

OK, makes sense now.

Cheers

Kenny 

>
>Aaron

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

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

[Aaron Zauner]

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 repeated nonces,
> but not the encryption key. The effect may be bad - but it's perhaps not
> as catastrophic in practice as the authenticity attack.

Ah, I see. Yes and we do not consider this in our paper at all. Maybe we 
should? Not sure how practical this is.

> Think about it this way: for your injection attack, you need to recover
> the CTR keystream - otherwise you couldn't properly AES-GCM-encrypt your
> chosen plaintext record for the injection. But if you recovered the
> keystream as part of your attack, then you've also recovered the plaintext
> for the original record.
> 
> Or maybe in your injection attack you were assuming you already *knew* the
> plaintext? That would make sense, I guess - a lot easier then to recover
> the keystream than doing the "undoing the XOR" attack needed to recover
> P_1 and P_2 from P_1 XOR P_2.

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.

Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Paterson, Kenny]

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 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) with
>> high probability using standard techniques (see the paper by Mason et al
>> at CCS 2006 for a full account of this step).
>> 
>> In the TLS context, this means using the same 64-bit nonce_explicit in a
>> given connection - because then opaque salt will be the same 32-bit
>>value.
>> 
>> This condition is detectable by an adversary because the nonce_explicit
>> part is sent on the wire (the clue is in the name!).
>> 
>> You don't need to know the full 96-bit nonce to carry out the attack.
>
>Yes, I understood that, of course. But:
>
>> Once you've recovered a plaintext, you can also recover the
>>corresponding
>> CTR-mode keystream. Together with the integrity key, this now enables
>> packet forgery attacks for arbitrary plaintexts (of length limited by
>>that
>> of the known keystream).
>
>Right. Joux's attack doesn't recover a plaintext of the actual TLS
>session, we attack GHASH in this case and factor possible candidate
>polynomials of the /authentication key/. In this context I assume
>'confidentiality compromise' with: somebody can recover plaintext from
>captured TLS records. At least in our attack this isn't the case. We're
>merely able to inject malicious content. Am I amiss? Or am I just
>confused about nomenclature?

I think you are amiss.

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 repeated nonces,
but not the encryption key. The effect may be bad - but it's perhaps not
as catastrophic in practice as the authenticity attack.

Think about it this way: for your injection attack, you need to recover
the CTR keystream - otherwise you couldn't properly AES-GCM-encrypt your
chosen plaintext record for the injection. But if you recovered the
keystream as part of your attack, then you've also recovered the plaintext
for the original record.

Or maybe in your injection attack you were assuming you already *knew* the
plaintext? That would make sense, I guess - a lot easier then to recover
the keystream than doing the "undoing the XOR" attack needed to recover
P_1 and P_2 from P_1 XOR P_2.

Cheers

Kenny  


>
>Thank you,
>Aaron

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

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

[Aaron Zauner]

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 produces the XOR of the plaintexts,
> from which the two individual plaintexts can be recovered (usually) with
> high probability using standard techniques (see the paper by Mason et al
> at CCS 2006 for a full account of this step).
> 
> In the TLS context, this means using the same 64-bit nonce_explicit in a
> given connection - because then opaque salt will be the same 32-bit value.
> 
> This condition is detectable by an adversary because the nonce_explicit
> part is sent on the wire (the clue is in the name!).
> 
> You don't need to know the full 96-bit nonce to carry out the attack.

Yes, I understood that, of course. But:

> Once you've recovered a plaintext, you can also recover the corresponding
> CTR-mode keystream. Together with the integrity key, this now enables
> packet forgery attacks for arbitrary plaintexts (of length limited by that
> of the known keystream).

Right. Joux's attack doesn't recover a plaintext of the actual TLS session, we 
attack GHASH in this case and factor possible candidate polynomials of the 
/authentication key/. In this context I assume 'confidentiality compromise' 
with: somebody can recover plaintext from captured TLS records. At least in our 
attack this isn't the case. We're merely able to inject malicious content. Am I 
amiss? Or am I just confused about nomenclature?

Thank you,
Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Paterson, Kenny]

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) with
high probability using standard techniques (see the paper by Mason et al
at CCS 2006 for a full account of this step).

In the TLS context, this means using the same 64-bit nonce_explicit in a
given connection - because then opaque salt will be the same 32-bit value.

This condition is detectable by an adversary because the nonce_explicit
part is sent on the wire (the clue is in the name!).

You don't need to know the full 96-bit nonce to carry out the attack.

Once you've recovered a plaintext, you can also recover the corresponding
CTR-mode keystream. Together with the integrity key, this now enables
packet forgery attacks for arbitrary plaintexts (of length limited by that
of the known keystream).

IIRC, we discussed this by e-mail some months back...

Regards,

Kenny



On 16/05/2016 10:04, "TLS on behalf of Aaron Zauner"  wrote:

>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.  Instead, the salt is generated as part of the handshake
>   process: it is either the client_write_IV (when the client is
>   sending) or the server_write_IV (when the server is sending).  The
>   salt length (SecurityParameters.fixed_iv_length) is 4 octets.
>```
>
>As you can see the salt is is implicitly derived from the *_write_IV. We
>have no influence on this part of the IV construction, whereas the
>`nonce_explicit` is generated by the implementer. I don't see a way how
>we could XOR some records and compromise confidentiality, we've checked,
>believe me. If somebody can come up with an attack though, that'd be nice.
>
>On the catastrophic part: I'd like to keep it around. I don't think it
>deserves a name like a hurricane, but catastrophic is pretty spot on in
>this regard.
>
>w.r.t. nonce/n-nonce: either we keep the parentheses with "number used
>once" around or we change it to n-once as suggested by Tony and
>beautifully pronounced by Adam Langley :)
>
>Aaron

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

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

[Aaron Zauner]

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.  Instead, the salt is generated as part of the handshake
   process: it is either the client_write_IV (when the client is
   sending) or the server_write_IV (when the server is sending).  The
   salt length (SecurityParameters.fixed_iv_length) is 4 octets.
```

As you can see the salt is is implicitly derived from the *_write_IV. We have 
no influence on this part of the IV construction, whereas the `nonce_explicit` 
is generated by the implementer. I don't see a way how we could XOR some 
records and compromise confidentiality, we've checked, believe me. If somebody 
can come up with an attack though, that'd be nice.

On the catastrophic part: I'd like to keep it around. I don't think it deserves 
a name like a hurricane, but catastrophic is pretty spot on in this regard.

w.r.t. nonce/n-nonce: either we keep the parentheses with "number used once" 
around or we change it to n-once as suggested by Tony and beautifully 
pronounced by Adam Langley :)

Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> 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 
> any two packets processed under the same nonce, but TLS sessions can also be 
> attacked through forgery by an adversary. For example, in the case of HTTPS 
> sessions content injection, XSS, and other attack vectors are possible.

s/XOR of any two packets/XOR of any two records/

This is TLS, not IPsec. And yes, this looks fine.

Yoav

> 
> 
> Original text:
> 
> Security of AES-GCM requires that the "nonce" (number used once) is
> never reused. The IV construction in Section 3 does not prevent
> implementers from reusing the nonce by mistake. It is paramount that
> the implementer be aware of the security implications when a nonce
> is re-used even once.
> 
> Nonce re-use in AES-GCM results in catastrophic failure of it's
> authenticity. Hence, TLS sessions can be effectively attacked through
> forgery by an adversary. In the case of e.g. HTTPS sessions content
> injection is possible, XSS and other attack vectors.
> 
> 
> On 2016-05-16 05:32, Peter Gutmann wrote:
>> 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 they'll get the correct definition, and if
>> they use Wikipedia they'll get Wikipedia's definition.
>>> I wouldn't cite Wikipedia in an academic publication, but it's what pops up
>>> first if someone looks for "nonce" via a Google search
>> That doesn't make it correct, it just makes it the most popular 
>> misconception.
>> For another crypto example, look up HDCP and Blom's Scheme on Wikipedia, and
>> see how much resemblance that bears to reality.
>>> This document is on TLS cipher-suites, not AES-GCM in general. This attack
>>> isn't applicable here for various reasons. But I agree that the errata could
>>> be clearer here. What'd be your suggestion as an addition or change? I'm 
>>> sure
>>> the relevant editors will be willing to amend/change my wording in this
>>> errata.
>> Since the paper for the Black Hat talk hasn't been published, I don't know
>> what the actual problem is (and by extension what the various reasons are),
>> but if you reuse a nonce I can't see how it would affect auth but not
>> confidentiality, since you'd be generating a repeated cipher stream.  If
>> confidentiality isn't affected then there should probably be a note 
>> explaining
>> why, since my immediate reaction to a comment about nonce reuse would be
>> "complete failure of the entire mode".
>> Peter.
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

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

[Peter Gutmann]

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)

[Atul Luykx]

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 through forgery by an adversary. For example, in 
the case of HTTPS sessions content injection, XSS, and other attack 
vectors are possible.



Original text:

Security of AES-GCM requires that the "nonce" (number used once) is
never reused. The IV construction in Section 3 does not prevent
implementers from reusing the nonce by mistake. It is paramount that
the implementer be aware of the security implications when a nonce
is re-used even once.

Nonce re-use in AES-GCM results in catastrophic failure of it's
authenticity. Hence, TLS sessions can be effectively attacked through
forgery by an adversary. In the case of e.g. HTTPS sessions content
injection is possible, XSS and other attack vectors.


On 2016-05-16 05:32, Peter Gutmann wrote:

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 they'll get the correct definition, 
and if

they use Wikipedia they'll get Wikipedia's definition.

I wouldn't cite Wikipedia in an academic publication, but it's what 
pops up

first if someone looks for "nonce" via a Google search


That doesn't make it correct, it just makes it the most popular 
misconception.
For another crypto example, look up HDCP and Blom's Scheme on 
Wikipedia, and

see how much resemblance that bears to reality.

This document is on TLS cipher-suites, not AES-GCM in general. This 
attack
isn't applicable here for various reasons. But I agree that the errata 
could
be clearer here. What'd be your suggestion as an addition or change? 
I'm sure
the relevant editors will be willing to amend/change my wording in 
this

errata.


Since the paper for the Black Hat talk hasn't been published, I don't 
know
what the actual problem is (and by extension what the various reasons 
are),

but if you reuse a nonce I can't see how it would affect auth but not
confidentiality, since you'd be generating a repeated cipher stream.  
If
confidentiality isn't affected then there should probably be a note 
explaining
why, since my immediate reaction to a comment about nonce reuse would 
be

"complete failure of the entire mode".

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


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

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

[Peter Gutmann]

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 they'll get the correct definition, and if
they use Wikipedia they'll get Wikipedia's definition.

>I wouldn't cite Wikipedia in an academic publication, but it's what pops up
>first if someone looks for "nonce" via a Google search

That doesn't make it correct, it just makes it the most popular misconception.
For another crypto example, look up HDCP and Blom's Scheme on Wikipedia, and
see how much resemblance that bears to reality.

>This document is on TLS cipher-suites, not AES-GCM in general. This attack
>isn't applicable here for various reasons. But I agree that the errata could
>be clearer here. What'd be your suggestion as an addition or change? I'm sure
>the relevant editors will be willing to amend/change my wording in this
>errata.

Since the paper for the Black Hat talk hasn't been published, I don't know
what the actual problem is (and by extension what the various reasons are),
but if you reuse a nonce I can't see how it would affect auth but not
confidentiality, since you'd be generating a repeated cipher stream.  If
confidentiality isn't affected then there should probably be a note explaining
why, since my immediate reaction to a comment about nonce reuse would be
"complete failure of the entire mode".

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

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

[Judson Wilson]

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 is number that is
only used once, the word is not derived from omitting letters from the
phrase, so we shouldn't mislead people into believing that. Removing the
scare quotes is sufficient to prevent this misunderstanding.

On Sun, May 15, 2016 at 7:23 PM, Joseph Salowey  wrote:

>
> 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 results in catastrophic
>> > failure of the entire mode, both confidentiality and
>> integrity/authenticity.
>>
>> I'd like to add that I don't see a difference between a "failure" and a
>> "catastrophic failure".  It's probably better to stay away from subjective
>> words like that.
>>
>>
> [Joe] It would be better to state what actually fails:
>
> "Nonce re-use in AES-GCM allows for the recovery of the authentication
> key resulting in complete failure of the mode's authenticity.  Hence, TLS
> sessions can be effectively attacked through forgery by an adversary.
> This enables an attacker to inject data into the TLS allowing for XSS and
> other attack vectors. "
>
>
>
>> -Rick
>>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

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 results in catastrophic
> > failure of the entire mode, both confidentiality and
> integrity/authenticity.
>
> I'd like to add that I don't see a difference between a "failure" and a
> "catastrophic failure".  It's probably better to stay away from subjective
> words like that.
>
>
[Joe] It would be better to state what actually fails:

"Nonce re-use in AES-GCM allows for the recovery of the authentication key
resulting in complete failure of the mode's authenticity.  Hence, TLS
sessions can be effectively attacked through forgery by an adversary.  This
enables an attacker to inject data into the TLS allowing for XSS and other
attack vectors. "



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

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

[Tony Arcieri]

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
> wording for this specific paragraph?
>

I think "nonce" meaning number used once is fine for cryptographic
purposes.

I'd also note Adam Langley has taken to pronouncing the word nonce as
"n-once", at least at this year's RWC.

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

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

[Aaron Zauner]

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.
> "nonce" is from medieval English, and predates modern cryptography and IVs
> by
> about 800 years.
>

Sure, I wouldn't cite Wikipedia in an academic publication, but it's what
pops up first if someone looks for "nonce" via a Google search. That was my
point. In general I think the wording should be more clear and a little
less of crypto-only nomenclature, thus -- maybe -- more convenient for
engineers. I suspect this was one of the issues with the document and why
we found vulnerable implementations in the first place. If you read
carefully and do your home-work the RFC in current form pretty much tells
you that you shouldn't re-use the nonce. Compared to TLS 1.3 and the
ChaCha20/Poly1305 document (and my OCB draft): the construction does not
prevent implementers from re-using the same nonce by mistake. Ideally it
would be handled in such a way that human error results in
non-interoperable implementations, like with said drafts and 1.3. But as
noted: it'll probably cause massive breakage among deployed implementations
and may even be the cause for more security issues with implementations to
pop up.

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 wording
for this specific paragraph?


>
> >In TLS nonce reuse allows us to attack the authentication key of GCM. Not
> the
> >actual master secret. There's no direct break of the confidentiality,
>
> If you reuse the IV/nonce in GCM (or more specifically CTR mode), you
> repeat
> the cipher stream.  An XOR makes it go away, so you lose any
> confidentiality.
>

This document is on TLS cipher-suites, not AES-GCM in general. This attack
isn't applicable here for various reasons. But I agree that the errata
could be clearer here. What'd be your suggestion as an addition or change?
I'm sure the relevant editors will be willing to amend/change my wording in
this errata.

More feedback is always appreciated. I suggest people on this list comment
as much as they think is relevant to this errata, we should get it perfect
this time around. It should be as clear as possible and be understood by
everyone - otherwise the errata doesn't make any sense.

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

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

[Aaron Zauner]

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 erratum.

No problem, but:
>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
integrity/authenticity.
>

What do you think nonce stands for?
https://en.wikipedia.org/wiki/Cryptographic_nonce

In TLS nonce reuse allows us to attack the authentication key of GCM. Not
the actual master secret. There's no direct break of the confidentiality,
just authenticity (and thus integrity). For HTTPS this allows us to inject
content which then may lead to a compromise of the session confidentiality.

Maybe I misunderstood what you meant.

Aaron

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

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

[Peter Gutmann]

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 TLS nonce reuse allows us to attack the authentication key of GCM. Not the
>actual master secret. There's no direct break of the confidentiality, 

If you reuse the IV/nonce in GCM (or more specifically CTR mode), you repeat
the cipher stream.  An XOR makes it go away, so you lose any confidentiality.

Peter.


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

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

[Rick van Rein]

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 integrity/authenticity.

I'd like to add that I don't see a difference between a "failure" and a
"catastrophic failure".  It's probably better to stay away from subjective
words like that.

-Rick

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

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

[Peter Gutmann]

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 doesn't just result in
"catastrophic failure of it's authenticity", it results in catastrophic
failure of the entire mode, both confidentiality and integrity/authenticity.

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

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

[RFC Errata System]

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: Technical
Reported by: Aaron Zauner 

Section: 6.1

Original Text
-
   AES-GCM security requires that the counter is never reused.  The IV
   construction in Section 3 is designed to prevent counter reuse.

   Implementers should also understand the practical considerations of
   IV handling outlined in Section 9 of [GCM].

Corrected Text
--
   Security of AES-GCM requires that the "nonce" (number used once) is 
   never reused. The IV construction in Section 3 does not prevent 
   implementers from reusing the nonce by mistake. It is paramount that 
   the implementer be aware of the security implications when a nonce 
   is re-used even once. 

   Nonce re-use in AES-GCM results in catastrophic failure of it's
   authenticity. Hence, TLS sessions can be effectively attacked through
   forgery by an adversary. In the case of e.g. HTTPS sessions content
   injection is possible, XSS and other attack vectors.

Notes
-
Obviously the original wording is so ambiguous that implementers got it wrong 
in the real world. Related to: 
https://www.blackhat.com/us-16/briefings.html#nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls

It may be worth adding a reference to [JOUX] 
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/...38.../GCM/Joux_comments.pdf
 and maybe the paper we're intending to release on the actual HTTPS 
forgery/injection attack.

I'd actually like to change the nonce construction to that of the 
ChaCha20/Poly1305 document, but I figure this will cause massive breakage for 
already deployed implementations. TLS 1.3 fixes this issue per design.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC5288 (draft-ietf-tls-rsa-aes-gcm-03)
--
Title   : AES Galois Counter Mode (GCM) Cipher Suites for TLS
Publication Date: August 2008
Author(s)   : J. Salowey, A. Choudhury, D. McGrew
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Area: Security
Stream  : IETF
Verifying Party : IESG

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