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

From: Sean Turner <[email-masked]>
Date: Fri, 10 Feb 2017 00:07:35 -0500

All,

We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Fri, 10 Feb 2017 08:19:05 +0300

Dear Sean, dear all,

I find the existing limits quite reasonable and would prefer that we'll
stay conservative here, so I'd prefer option a) go with the existing text.

Best regards,
Stanislav Smyshlyaev

2017-02-10 8:07 GMT+03:00 Sean Turner <[email-masked]>:

> All,
>
> We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13
> Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits
> have been discussed a couple of times and we need to resolve once and for
> all whether the TLS WG wants to:
>
> Please indicate you preference to the TLS mailing list before Feb 17.
> Note that unless there’s clear consensus to change the text will remain as
> is (i.e., option a).
>
> J&S
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Feb 2017 16:44:58 +1100

> a) Close these two PRs and go with the existing text [0]

a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 10 Feb 2017 09:06:07 +0000

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 security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security proof
for AES-GCM.

Regards,

Kenny

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Feb 2017 13:26:17 +0200

> very confusing and easily open to misinterpretation.

I couldn't make out what b) says, c) is much clearer.

However, even in a), let alone b) or c), the limits are so high that
one should do some greasing, or this feature seems like a prime
candidate for rusting shut.

-Ilari

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Fri, 10 Feb 2017 12:38:34 +0000

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 encrypted with  AES-GCM in a session is 2^48 128-bit blocks (2^52 bytes), assuming  probability of success at 1/2^32" is not clear.  What is the success here? And, with 2^48 (full or partial) blocks, the collision probability is below (not at) 2^(-32).

And, "safely encrypted", what does this mean? I would like not having a collision among 128-bit blocks of ciphertexts, but I dont see any damage to the data owner who sends the encrypted data over a TLS session.

I copied the text that I later proposed under the discussion of PR#769 below.

" To use AES-GCM to provide authenticity of authenticated data, confidentiality of plaintext content, and information leakage [0] protection for the plaintext safely, the limit of total ciphertext under a single key is ( (TLSCipherText.length / 16) / ceiling (TLSCipherText.length / 16) ) times 2^48 128-bit blocks.

When the data limit is reached, the chance of having a collision among 128-bit blocks of the ciphertext is below 2^(-32) which is negligible.

Since the block size of AES is 128 bits, there will be collisions among different sets of ciphertext from multiple sessions using GCM (or any other modes of AES) when the total amount of the ciphertext of all considered sessions is more than 2^64 128-bit blocks. This fact does not seem to create a practical security weakness of using AES GCM.

For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached. See [AEAD-LIMITS] for further analysis.

[0]: Information leakage in the context of TLS is a chosen-plaintext distinguishing attack where the attacker provides 2 128-bit plaintext blocks to a GCM encryption engine, after seeing one encrypted block for one of the 2 plaintext blocks, the attacker knows which plaintext block was encrypted. Or, it means that there is a collision among 128-bit blocks of the ciphertext. "

  1.  The text above uses blocks instead of bytes or records of ciphertext.
  2.  The partial block situation is taken into account.

"

Or, using good text from PR769 provided by brainhub, the first paragraph could be replaced by the following.

"To use AES-GCM to provide authenticity of authenticated data, confidentiality of plaintext content, and information leakage [0] protection for the plaintext, the limit of total ciphertext under a single key is 2^48 128-bit blocks with the ciphertext size being rounded up to the next 16-byte boundary. "

Regards,

Quynh.

________________________________
From: Cfrg <[email-masked]> on behalf of Sean Turner <[email-masked]>
Sent: Friday, February 10, 2017 12:07:35 AM
To: <[email-masked]>
Cc: IRTF CFRG
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

All,

J&S

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Fri, 10 Feb 2017 12:48:41 +0000

Hi Kenny,

From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of "Paterson, Kenny" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 10, 2017 at 4:06 AM
To: Sean Turner <[email-masked]<mailto:[email-masked]>>
Cc: IRTF CFRG <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi,

My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as being a counter-mode encryption and each counter is a 96-bit nonce || 32-bit counter. I don’t know if there is another kind of proof that is more precise than that.

Regards,
Quynh.

Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On 10 February 2017 at 16:07, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Rene Struik <[email-masked]>
Date: Fri, 10 Feb 2017 10:51:39 -0500

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] 
<https://tlswg.github.io/tls13-spec/#AEAD-LIMITS>provides an analysis of 
these limits under the assumption that the underlying primitive (AES or 
ChaCha20) has no weaknesses. Implementations SHOULD do a key 
updateSection 4.6.3 
<https://tlswg.github.io/tls13-spec/#key-update>prior to reaching these 
limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be 
encrypted on a given connection while keeping a safety margin of 
approximately 2^-57 for Authenticated Encryption (AE) security. For 
ChaCha20/Poly1305, the record sequence number would wrap before the 
safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel 
attacks, which - in some implementations - have been shown to be 
successful at recovering keying material with a relatively small number 
of messages encrypted using the same key. While results are highly 
implementation-specific, thereby making it hard to provide precise 
guidance, prudence suggests that implementations should not reuse keys 
ad infinitum. Implementations SHALL therefore always implement the key 
update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make 
sure people do not "forget" to implement key updates?}

See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 10 Feb 2017 17:22:32 +0000

Dear Quynh,

On 10/02/2017 12:48, "Dang, Quynh (Fed)" <[email-masked]> wrote:

>My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as
>being a counter-mode encryption and each counter is a 96-bit nonce ||
>32-bit counter. I don’t know if there is another kind of proof that is
>more precise than that.

Thanks for explaining. I think, then, that what you are doing is (in
effect) accounting for the PRP/PRF switching lemma that is used (in a
standard way) as part of the IND-CPA security proof of AES-GCM. One can
obtain a greater degree of precision by using the proven bounds for
IND-CPA security of AES-GCM. These incorporate the "security loss" coming
from the PRP/PRF switching lemma. The current best form of these bounds is
due to Iwata et al.. This is precisely what we analyse in the note at
http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf - specifically, see
equations (5) - (7) on page 6 of that note.

Regards,

Kenny

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Fri, 10 Feb 2017 18:47:57 +0000

Hi Rene,

From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of Rene Struik <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Cc: IRTF CFRG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Dear colleagues:

There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys. [AEAD-LIMITS]<https://tlswg.github.io/tls13-spec/#AEAD-LIMITS> provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key update Section 4.6.3<https://tlswg.github.io/tls13-spec/#key-update> prior to reaching these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of approximately 2^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached.

The above upper limits do not take into account potential side channel attacks, which - in some implementations - have been shown to be successful at recovering keying material with a relatively small number of messages encrypted using the same key. While results are highly implementation-specific, thereby making it hard to provide precise guidance, prudence suggests that implementations should not reuse keys ad infinitum. Implementations SHALL therefore always implement the key update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make sure people do not "forget" to implement key updates?}

How do you do side channel attacks on TLS ? Do these side-channel attacks work for AES-GCM only in TLS 1.3 ?

All,

J&S

[email-masked]<mailto:[email-masked]>https://www.irtf.org/mailman/listinfo/cfrg

--
email: [email-masked]<mailto:[email-masked]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Fri, 10 Feb 2017 18:56:36 +0000

Dear Kenny,

From: "Paterson, Kenny" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 10, 2017 at 12:22 PM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>, Sean Turner <[email-masked]<mailto:[email-masked]>>
Cc: IRTF CFRG <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: 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)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kenny,

Hi,

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
proof
for AES-GCM.

I reviewed the paper more than once. I highly value the work. I suggested to reference  your paper in the text.  I think the result in your paper is the same with what is being suggested when the collision probability allowed is 2^(-32).

Regards,
Quynh.

Regards,

Kenny

Regards,
Quynh.

---

From: Rene Struik <[email-masked]>
Date: Fri, 10 Feb 2017 14:02:14 -0500

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 
not merely study I/O behavior of crypto contructs, but also looks into 
what information can be obtained from what is going on "under the hood" 
of the computations (power consumption, radiation, timing, etc; or even 
invasive attacks). Most commonly one looks at crypto building blocks, 
but ultimately side channels can comprise any system behavior ("Lucky13" 
does, e.g., exploit this, if I remember correctly).

 From the last page of [2]: Finally, the most important conclusion from 
this paper is that it is not only a necessity but also a must, in the 
coming version of FIPS 140-3 standard, to evaluate cryptographic modules 
for their resistivity against SCA attacks.

Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis 
Attacks - Revealing the Secrets of Smart Cards", Springer, 2007.
[2] 
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf
[2]

On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:
> Hi Rene,
>
> From: TLS <[email-masked] <mailto:[email-masked]>> on 
> behalf of Rene Struik <[email-masked] 
> <mailto:[email-masked]>>
> To: Sean Turner <[email-masked] <mailto:[email-masked]>>, 
> "<[email-masked] <mailto:[email-masked]>>" <[email-masked] 
> <mailto:[email-masked]>>
> Cc: IRTF CFRG <[email-masked] <mailto:[email-masked]>>
>     There are cryptographic limits on the amount of plaintext which
>     can be safely encrypted under a given set of keys.[AEAD-LIMITS]
>     <https://tlswg.github.io/tls13-spec/#AEAD-LIMITS>provides an
>     analysis of these limits under the assumption that the underlying
>     primitive (AES or ChaCha20) has no weaknesses. Implementations
>     SHOULD do a key updateSection 4.6.3
>     <https://tlswg.github.io/tls13-spec/#key-update>prior to reaching
>     these limits.
>
>     For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
>     be encrypted on a given connection while keeping a safety margin
>     of approximately 2^-57 for Authenticated Encryption (AE) security.
>     For ChaCha20/Poly1305, the record sequence number would wrap
>     before the safety limit is reached.
>
>     The above upper limits do not take into account potential side
>     channel attacks, which - in some implementations - have been shown
>     to be successful at recovering keying material with a relatively
>     small number of messages encrypted using the same key. While
>     results are highly implementation-specific, thereby making it hard
>     to provide precise guidance, prudence suggests that
>     implementations should not reuse keys ad infinitum.
>     Implementations SHALL therefore always implement the key update
>     mechanism of Section 4.6.3.
>
>     {editorial note: perhaps, one should impose the limit 2^20, just
>     to make sure people do not "forget" to implement key updates?}
>
>
> How do you do side channel attacks on TLS ? Do these side-channel 
> attacks work for AES-GCM only in TLS 1.3 ?
>
>
>
>
>>     [0]https://tlswg.github.io/tls13-spec/#rfc.section.5.5
>>     [1]https://github.com/tlswg/tls13-spec/pull/765
>>     [2]https://github.com/tlswg/tls13-spec/pull/769
>>     [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>
>
>     -- 
>     email:[email-masked]  | Skype: rstruik

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 10 Feb 2017 19:06:46 +0000

Hi,

On 10/02/2017 18:56, "Dang, Quynh (Fed)" <[email-masked]> wrote:

>Dear Kenny, 
>
>From: "Paterson, Kenny" <[email-masked]>
>To: 'Quynh' <[email-masked]>, Sean Turner <[email-masked]>
>Cc: IRTF CFRG <[email-masked]>, "<[email-masked]>" <[email-masked]>
>I reviewed the paper more than once. I highly value the work. I suggested
>to reference  your paper in the text.  I think the result in your paper
>is the same with what is being suggested when the collision probability
>allowed is 2^(-32).

Thanks for this feedback. I guess my confusion arises from wondering what
you mean by collision probability and why you care about it. There are no
collisions in the block cipher's outputs per se, because AES is a
permutation for each choice of key. And collisions in the ciphertext
blocks output by AES-GCM are irrelevant to its formal security analysis.

On the other hand, when in the proof of IND-CPA security of AES-GCM one
switches from a random permutation (which is how we model AES) to a random
function (which is what we need to argue in the end that the plaintext is
masked by a one-time pad, giving indistinguishability), then one needs to
deal with the probability that collisions occur in the function's outputs
but not in the permutation's. This ends up being the main contribution to
the security bound in the proof for IND-CPA security.

Is that what you are getting at?

If so, then we are on the same page, and what remains is to decide whether
a 2^{-32} bound is a good enough security margin.

Regards,

Kenny

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Fri, 10 Feb 2017 19:36:27 +0000

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 <[email-masked]>
Sent: Friday, February 10, 2017 2:02:14 PM
To: Dang, Quynh (Fed); Sean Turner; <[email-masked]>
Cc: IRTF CFRG
Subject: 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 not merely study I/O behavior of crypto contructs, but also looks into what information can be obtained from what is going on "under the hood" of the computations (power consumption, radiation, timing, etc; or even invasive attacks). Most commonly one looks at crypto building blocks, but ultimately side channels can comprise any system behavior ("Lucky13" does, e.g., exploit this, if I remember correctly).

>From the last page of [2]: Finally, the most important conclusion from this paper is that it is not only a necessity but also a must, in the coming version of FIPS 140-3 standard, to evaluate cryptographic modules for their resistivity against SCA attacks.

Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis Attacks - Revealing the Secrets of Smart Cards", Springer, 2007.
[2] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf
[2]

Dear colleagues:

All,

J&S

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Sat, 11 Feb 2017 11:45:50 +0000

Hi Kenny,

AES-permutation is a permutation.  But, AES-GCM (AES in counter mode) is a PRF as long as the 128-bit IVs are unique under the encryption key.  The amount of plaintext is the same with the amount of ciphertext.

I originally talked about plaintext in my discussion, but several people asked me to talk about ciphertext instead (I thought maybe measuring ciphertext was easier than measuring plaintext in practice and that was why they asked me that).

The number of 128-bit blocks of plaintext is the same with the number of 128-bit "one-time pad" keys produced by the AES key and the unique 128-bit IVs. These 128-bit "one-time pad" keys and the corresponding 128-bit ciphertext blocks are the same in the sense that they are both sets of pseudo-random 128-bit blocks.  But, the 128-bit "one-time pad" keys are not stored, they have to either measure the amount of plaintext or ciphertext.

Regards,

Quynh.

________________________________
From: Paterson, Kenny <[email-masked]>
Sent: Friday, February 10, 2017 2:06:46 PM
To: Dang, Quynh (Fed); Sean Turner
Cc: IRTF CFRG; <[email-masked]>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi,

>Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
Limits on Authenticated Encryption Use in TLS - isg.rhul.ac.uk<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>
www.isg.rhul.ac.uk
Limits on Authenticated Encryption Use in TLS Atul Luykx and Kenneth G. Paterson March 8, 2016 Abstract Thistechnicalnotepresentslimitsonthesecurity(asafunctionofthe

Regards,

Kenny

---

From: Markulf Kohlweiss <[email-masked]>
Date: Mon, 13 Feb 2017 15:34:13 +0000

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point of view, especially for a confidentiality bound.

We verified an implementation of the TLS 1.3 record (https://eprint.iacr.org/2016/1178, to appear at Security & Privacy 2017) where we arrive at a combined bound for authenticity and confidentiality that is compatible with the Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

><cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com> wrote:
>
>>On 10 February 2017 at 16:07, Sean Turner <sean at sn3rd.com> wrote:
>>Cfrg at irtf.org

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Mon, 13 Feb 2017 15:45:36 +0000

Hi Markulf,

The probability of a bad thing to happen is actually below (or about) 2^(-33). It practically won’t happen when the chance is 1 in 2^32. And, to achieve that chance, you must collect 2^48 128-bit blocks.

Regards,
Quynh.

From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of Markulf Kohlweiss <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" <[email-masked]<mailto:[email-masked]>>, Sean Turner <[email-masked]<mailto:[email-masked]>>
Cc: Antoine Delignat-Lavaud <[email-masked]<mailto:[email-masked]>>, IRTF CFRG <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hello,

Regards,

Hi,

Regards,

Kenny

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 14 Feb 2017 01:21:25 +0200

> On 10 Feb 2017, at 07:07, Sean Turner <[email-masked]> wrote:
> 
> All,
> 

I thought the cited paper sorted this out like a year ago.

In favor of option a

Aaron

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 13 Feb 2017 15:25:06 -0800

> I thought the cited paper sorted this out like a year ago.

I am also in favor of option A.

The wording in option B is simultaneously much more unclear and much more
verbose. I consider it a regression.

Option C is more similar to option A, but not an improvement, IMO.

-- 
Tony Arcieri

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Feb 2017 11:59:44 +0000

Hi Markulf and all,

I provided more explanation below.

From: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss <[email-masked]<mailto:[email-masked]>>, "Paterson, Kenny" <[email-masked]<mailto:[email-masked]>>, Sean Turner <[email-masked]<mailto:[email-masked]>>
Cc: Antoine Delignat-Lavaud <[email-masked]<mailto:[email-masked]>>, IRTF CFRG <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Markulf,

Regards,
Quynh.

Hello,

When someone says AES-128 has 128 bits of security he or she means that 2^128 AES operations will break the cipher with probability 100%: finding the key and the plaintext.  It does not mean that attackers have only 2^(-128) chance of success. If an attacker could run 2^100 AES operations, his or her chance of success is way below 2^(-32): this does not mean that AES has a security level of 2^(-32) or  2^(-28).

The success probability 1/2^32 means that after 2^48 AES operations, the attacker has a success probability of 2^-32 which is practically zero.

Also, many users don’t know what “confidentiality bound” means.

The current text Eric wrote talks about a number 2^24.5 of full-size records. In many situations, the record sizes are not full size, but different sizes. My latest suggestion text does not assume full size records, it covers variable record sizes, it just counts AES-input blocks or AES operations.

Regards,
Quynh.

Regards,

Hi,

Regards,

Kenny

---

From: Atul Luykx <[email-masked]>
Date: Tue, 14 Feb 2017 08:17:53 -0800

Hey Quynh,

> When someone says AES-128 has 128 bits of security he or she means
> that 2^128 AES operations will break the cipher with probability 100%:
> finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext 
pairs available to the adversary, it will still take roughly 2^128 
operations to recover the key with AES. This contrasts with any mode of 
operation, where adversarial success probability increases according to 
the amount of data available and the computational complexity required 
to perform such an attack is not the limiting factor (which is the core 
of the problem we're discussing right now).

Regardless, correct me if I'm wrong Quynh, but you seem to have two 
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of 
caution instead of recommending that people switch when adversaries have 
success probability 2^{-32}. I don't see the discussion progressing on 
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough 
heuristic, however this can be fixed easily by minimally modifying the 
original text.

Atul

On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
>  From: 'Quynh' <[email-masked]>
> To: Markulf Kohlweiss <[email-masked]>, "Paterson, Kenny"
> <[email-masked]>, Sean Turner <[email-masked]>
> Cc: Antoine Delignat-Lavaud <[email-masked]>, IRTF CFRG
> <[email-masked]>, "<[email-masked]>" <[email-masked]>
>> The probability of a bad thing to happen is actually below (or
>> about) 2^(-33). It practically won’t happen when the chance is 1
>> in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
>> blocks.
>> 
>> Regards,
>> Quynh.
>> 
>> From: TLS <[email-masked]> on behalf of Markulf Kohlweiss
>> <[email-masked]>
>> To: "Paterson, Kenny" <[email-masked]>, Sean Turner
>> <[email-masked]>
>> Cc: Antoine Delignat-Lavaud <[email-masked]>, IRTF CFRG
>> <[email-masked]>, "<[email-masked]>" <[email-masked]>
>>> A security level of 2^-32 seems too low from a provable security
>>> point of view, especially for a confidentiality bound.
> 
> When someone says AES-128 has 128 bits of security he or she means
> that 2^128 AES operations will break the cipher with probability 100%:
> finding the key and the plaintext.  It does not mean that attackers
> have only 2^(-128) chance of success. If an attacker could run 2^100
> AES operations, his or her chance of success is way below 2^(-32):
> this does not mean that AES has a security level of 2^(-32) or
> 2^(-28).
> 
> The success probability 1/2^32 means that after 2^48 AES operations,
> the attacker has a success probability of 2^-32 which is practically
> zero.
> 
> The current text Eric wrote talks about a number 2^24.5 of full-size
> records. In many situations, the record sizes are not full size, but
> different sizes. My latest suggestion text does not assume full size
> records, it covers variable record sizes, it just counts AES-input
> blocks or AES operations.
> 
> Regards,
> Quynh.
> 
>> We verified an implementation of the TLS 1.3 record
>> (https://eprint.iacr.org/2016/1178, to appear at Security & Privacy
>> 2017) where we arrive at a combined bound for authenticity and
>> confidentiality that is compatible with the Iwata et al. bound.
>> 
>> Regards,
> [email-masked]
> [email-masked]

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Feb 2017 18:20:12 +0000

Hi Atul,

From: Atul Luykx <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 14, 2017 at 11:17 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Cc: Markulf Kohlweiss <[email-masked]<mailto:[email-masked]>>, Antoine Delignat-Lavaud <[email-masked]<mailto:[email-masked]>>, IRTF CFRG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hey Quynh,

operations to recover the key with AES.

Actually the same claim: my claim did not require any data requirement: just one ciphertext block.

This contrasts with any mode of

IND-CPA is important. That is why I have always been supporting it. Data is equivalent to computation in the sense that data are produced by computation. 2^x blocks = 2^x AES operations.

With 2^48 AES operations/input blocks, the actual margin is below 2^(-33). And, 1 in 2^32 is 1 in 4,294, 967,296.00 which is safe.

Quynh.

Atul

On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
  From: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss <[email-masked]<mailto:[email-masked]>>, "Paterson, Kenny"
<[email-masked]<mailto:[email-masked]>>, Sean Turner <[email-masked]<mailto:[email-masked]>>
Cc: Antoine Delignat-Lavaud <[email-masked]<mailto:[email-masked]>>, IRTF CFRG
<[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Hi Markulf,
The probability of a bad thing to happen is actually below (or
about) 2^(-33). It practically won’t happen when the chance is 1
in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
blocks.
Regards,
Quynh.
From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of Markulf Kohlweiss
<[email-masked]<mailto:[email-masked]>>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" <[email-masked]<mailto:[email-masked]>>, Sean Turner
<[email-masked]<mailto:[email-masked]>>
Cc: Antoine Delignat-Lavaud <[email-masked]<mailto:[email-masked]>>, IRTF CFRG
<[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
PRs (#765/#769)
Hello,
Our analysis of miTLS also supports option a)
A security level of 2^-32 seems too low from a provable security
point of view, especially for a confidentiality bound.
When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.  It does not mean that attackers
have only 2^(-128) chance of success. If an attacker could run 2^100
AES operations, his or her chance of success is way below 2^(-32):
this does not mean that AES has a security level of 2^(-32) or
2^(-28).
The success probability 1/2^32 means that after 2^48 AES operations,
the attacker has a success probability of 2^-32 which is practically
zero.
Also, many users don’t know what “confidentiality bound” means.
The current text Eric wrote talks about a number 2^24.5 of full-size
records. In many situations, the record sizes are not full size, but
different sizes. My latest suggestion text does not assume full size
records, it covers variable record sizes, it just counts AES-input
blocks or AES operations.
Regards,
Quynh.
We verified an implementation of the TLS 1.3 record
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy
2017) where we arrive at a combined bound for authenticity and
confidentiality that is compatible with the Iwata et al. bound.
Regards,
Markulf (for the miTLS team)
Hi,
My preference is to go with the existing text, option a).
2^{-32} instead of 2^{-60}). I can live with that, but the WG should
be
<cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com>
wrote:
I could live with c, but I'm opposed to b. It just doesn't make
sense.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Feb 2017 18:45:55 +0000

Hi Sean and all,

Beside my suggestion at https://www.ietf.org/mail-archive/web/tls/current/msg22381.html, I have a second suggestion below.

Just replacing this sentence: "

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
   encrypted on a given connection while keeping a safety margin of
   approximately 2^-57 for Authenticated Encryption (AE) security.

" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48 (partial or full) input blocks may be encrypted with one key. For other suggestions and analysis, see the referred paper above."

Regards,

Quynh.

________________________________
From: Dang, Quynh (Fed)
Sent: Tuesday, February 14, 2017 1:20:12 PM
To: Atul Luykx; Dang, Quynh (Fed)
Cc: Markulf Kohlweiss; Antoine Delignat-Lavaud; IRTF CFRG; [email-masked]
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Atul,

Hey Quynh,

Quynh.

Atul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Feb 2017 21:45:32 +0200

Hi, Quynh

> On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> Hi Sean and all,
> 
> Beside my suggestion at https://www.ietf.org/mail-archive/web/tls/current/msg22381.html <https://www.ietf.org/mail-archive/web/tls/current/msg22381.html>, I have a second suggestion below.
> 

I like the suggestion, but I’m probably missing something pretty basic about it.

2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or (since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10 blocks.

Why is that 2^48 input blocks rather than 2^34.5 input blocks?

Thanks

Yoav

---

From: Atul Luykx <[email-masked]>
Date: Tue, 14 Feb 2017 13:52:04 -0800

> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level. The original text 
recommends switching at 2^{34.5} input blocks, corresponding to a 
success probability of 2^{-60}, whereas his text recommends switching at 
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
>> Beside my suggestion at
>> https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
>> I have a second suggestion below.
>> 
>> " in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
>> (partial or full) input blocks may be encrypted with one key. For
>> other suggestions and analysis, see the referred paper above."
>> 
>> Regards,
>> Quynh.
> 
> 2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
> (since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
> blocks.
> 
> Links:
> ------
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Feb 2017 23:59:57 +0200

> On 14 Feb 2017, at 23:52, Atul Luykx <[email-masked]> wrote:
> 
> Because he wants to lower the security level. The original text recommends switching at 2^{34.5} input blocks, corresponding to a success probability of 2^{-60}, whereas his text recommends switching at 2^{48} blocks, corresponding to a success probability of 2^{-32}.

OK, missed that.

So I’m in favor of switching the phrasing to be about blocks rather than maximum-sized records, but not in favor of lowering the security level.

Yoav

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 15 Feb 2017 12:11:50 +0000

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir <[email-masked]<mailto:[email-masked]>>
Cc: 'Quynh' <[email-masked]<mailto:[email-masked]>>, IRTF CFRG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically the same: they are practically zero.  And, 2^-32 is an absolute chance in this case meaning that all attackers can’t improve their chance: no matter how much computational power the attacker has.

I don’t understand why the number 2^-60 is your special chosen number for this ? In your “theory”, 2^-112 would be in “higher” security than 2^-60.

Quynh.

The original text

Atul

On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>>
I like the suggestion, but I’m probably missing something pretty
basic about it.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 15 Feb 2017 13:46:28 +0000

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) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Atul,

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically the same: they are practically zero.

I'm not clear what you mean by "practically" here. They're clearly not the same as real numbers. And if we are being conservative about security, then the extremes in your list are a long way apart.

And, 2^-32 is an absolute chance in this case meaning that all attackers can’t improve their chance: no matter how much computational power the attacker has.

A sufficiently powerful adversary could carry out an exhaustive key search for GCM's underlying AES key. So I'm not sure what you're claiming here when you speak of "absolute chance".

I don’t understand why the number 2^-60 is your special chosen number for this ?

This is a bit subtle, but I'll try to explain in simple terms.

We can conveniently prove a bound of about this size (actually 2^-57) for INT-CTXT for a wide range of parameters covering both TLS and DTLS (where many verification failures may be permitted). Then, since we're ultimately interested in AE security, we would like to (roughly) match this for IND-CPA security, to get as good a bound as we can for AE security (the security bounds for the two notions sum to give an AE security bound - see page 2 of the "AE bounds" note).

In view of the INT-CTXT bound there's no point pushing the IND-CPA bound much lower than 2^-60 if the ultimate target is AE security. It just hurts the data limits more without significantly improving AE security.

Finally, 2^-60 is not *our* special chosen number. We wrote a note that contained a table of values, and it's worth noting that we did not make a specific recommendation in our note for which row of the table to select.

(Naturally, though, we'd like security to be as high as possible without making rekeying a frequent event. It's a continuing surprise to me that you are pushing for an option that actually reduces security when achieving higher security does not seem to cause any problems for implementors.)

In your “theory”, 2^-112 would be in “higher” security than 2^-60.

It certainly would, if it were achievable (which it is not for GCM without putting some quite extreme limits on data per key).

Cheers,

Kenny

Quynh.

The original text

Atul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Feb 2017 04:05:14 +1100

Kenny's response here is quite informative and clarifies this somewhat.

2^24.5 (the current text) is still a big number.  Though it might seem
a little small, I see no practical reason to change it.  In the most
perverse case, that means 520MB of one octet records (23MB of actual
data) before an update is forced.  It's hard to get excited about that
as a practical limitation.

Frankly, I'm more concerned that this isn't small enough and that it
could it be practical to deploy an implementation that don't support
KeyUpdate.  That would cause a real interop problem.

On 16 February 2017 at 00:46, Paterson, Kenny <[email-masked]> wrote:
> On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) <[email-masked]> wrote:
>
> Hi Atul,
>
> From: Atul Luykx <[email-masked]>
> To: Yoav Nir <[email-masked]>
> Cc: 'Quynh' <[email-masked]>, IRTF CFRG <[email-masked]>, "[email-masked]"
> <[email-masked]>
> I'm not clear what you mean by "practically" here. They're clearly not the
> same as real numbers. And if we are being conservative about security, then
> the extremes in your list are a long way apart.
>
> And, 2^-32 is an absolute chance in this case meaning that all attackers
> can’t improve their chance: no matter how much computational power the
> attacker has.
>
>
> A sufficiently powerful adversary could carry out an exhaustive key search
> for GCM's underlying AES key. So I'm not sure what you're claiming here when
> you speak of "absolute chance".
>
>
> We can conveniently prove a bound of about this size (actually 2^-57) for
> INT-CTXT for a wide range of parameters covering both TLS and DTLS (where
> many verification failures may be permitted). Then, since we're ultimately
> interested in AE security, we would like to (roughly) match this for IND-CPA
> security, to get as good a bound as we can for AE security (the security
> bounds for the two notions sum to give an AE security bound - see page 2 of
> the "AE bounds" note).
>
> In view of the INT-CTXT bound there's no point pushing the IND-CPA bound
> much lower than 2^-60 if the ultimate target is AE security. It just hurts
> the data limits more without significantly improving AE security.
>
> Finally, 2^-60 is not *our* special chosen number. We wrote a note that
> contained a table of values, and it's worth noting that we did not make a
> specific recommendation in our note for which row of the table to select.
>
> (Naturally, though, we'd like security to be as high as possible without
> making rekeying a frequent event. It's a continuing surprise to me that you
> are pushing for an option that actually reduces security when achieving
> higher security does not seem to cause any problems for implementors.)
>
> It certainly would, if it were achievable (which it is not for GCM without
> putting some quite extreme limits on data per key).
>
> Cheers,
>
> Kenny
>
> Quynh.
>
>
> The original text

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Feb 2017 19:20:39 +0200

> KeyUpdate.  That would cause a real interop problem.

Maybe we should resurrect [1] and add 3DES support so as to grease KeyUpdate.

No, not really, but TLS is not just the web, and there are connections that last for a long time and transfer large amounts of data. Think datacenter synchronization. At packet-sized records 24 million records amounts to 36 GB. That is considerably larger than a 4 GB software update I downloaded over HTTPS a few years ago, but not out of the ballpark.

Yoav

[1] https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05 <https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Feb 2017 04:25:35 +1100

On 16 February 2017 at 04:20, Yoav Nir <[email-masked]> wrote:
> No, not really, but TLS is not just the web, and there are connections that
> last for a long time and transfer large amounts of data. Think datacenter
> synchronization. At packet-sized records 24 million records amounts to 36
> GB. That is considerably larger than a 4 GB software update I downloaded
> over HTTPS a few years ago, but not out of the ballpark.

I realize that's going to require updates pretty often (once you open
up the CWND), but I don't think that it is frequent enough to be a
concern.

I well know that HTTP gets used at these volumes more often than
people realize.  I'd rather recommend ChaCha for those niche uses
though if the rate was sufficiently high.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Feb 2017 19:30:04 +0200

> On 15 Feb 2017, at 19:25, Martin Thomson <[email-masked]> wrote:
> 

And now I’ve lost you. A moment ago I thought you were concerned that people would fail to implement KeyUpdate. Are you now suggesting that it be removed entirely from TLS 1.3?

There’s no getting around the fact that AES-GCM is faster on certain processors than ChaCha, and speed is likely to be a major concern for exactly the same systems that use the high data volumes.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Feb 2017 04:33:21 +1100

> And now I’ve lost you. A moment ago I thought you were concerned that people would fail to implement KeyUpdate. Are you now suggesting that it be removed entirely from TLS 1.3?

No.  My point was that if GCM requires more updates than you can
handle (because you are running well in excess of 1Tbps perhaps, I
don't know, my crystal ball isn't that good), then use ChaCha where
you don't need to update so often.  Obviously there is a tradeoff
there given the relative availability of hardware support, which you
likely need at those rates, but again the crystal ball is imperfect in
telling us how that story plays out.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 16 Feb 2017 12:23:05 +0000

Hi Kenny,

I am glad to see that you enjoyed the discussion more than what you planed for the time on your vacation.  We love crypto and the IETF!

From: "Paterson, Kenny" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 15, 2017 at 8:46 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Cc: Atul Luykx <[email-masked]<mailto:[email-masked]>>, Yoav Nir <[email-masked]<mailto:[email-masked]>>, IRTF CFRG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Quynh,

Hi Atul,

I'm not clear what you mean by "practically" here.

As far as I know, such chance has not happened in history for any targeted search where the chance for hitting the target is 1 in 2^32.

They're clearly not the same as real numbers. And if we are being conservative about security, then the extremes in your list are a long way apart.

I described my point not in a best way, sorry. For key recovery, if an attacker can do 2^96 AES operations, his chance of finding the key is 2^-32, but this chance will get improved if the attacker does more computation. On the contrary, the chance for the distinguishing attack won’t change with the proposed data limit.

I just checked the paper. There is a small error I think. AES-GCM in TLS 1.3 is a prf. Under a given key, every input block or just one repeated block 2^35 times, their ciphertext blocks are 2^35 random 128-bit blocks assuming the key has 128 bits of entropy. If there is a collision among the ciphertext blocks, it does not mean anything because it does not say anything about the plaintext blocks.

I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60 are all safe choices. If someone wants to rekey sooner (or often) for operational reason or any other reason, that would be just fine. I just hope that we don’t have text which might imply that 2^-32 is not a safe choice.  In our guidelines, we basically indicate that 2^-32 or below is safe.

Cheers,

Kenny

I am going to propose another option and I hope that you and all other people will be happy with.

Thank you and Regards,
Quynh.

Quynh.

The original text

Atul

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 16 Feb 2017 21:33:39 +0200

> though if the rate was sufficiently high.

I agree with Yoav Nir here, it's certainly not a niche use* and one's implementation should not be forced to use a certain cipher mode if there would be better options (e.g. because -- as pointed out earlier -- hardware support is available).

* We'll all agree that most of the TLS traffic is made up by HTTPS requests, still, there are many other uses and we design protocols not just for the web. That's W3C.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 16 Feb 2017 21:51:22 +0200

> On 16 Feb 2017, at 14:23, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> Hi Kenny,
> 
> To: 'Quynh' <[email-masked]>
> Cc: Atul Luykx <[email-masked]>, Yoav Nir <[email-masked]>, IRTF CFRG <[email-masked]>, "[email-masked]" <[email-masked]>
>>> Cc: 'Quynh' <[email-masked]>, IRTF CFRG <[email-masked]>, "[email-masked]" <[email-masked]>

Maybe I don't comprehend what you're trying to propose - but why change this paragraph then?

Coming from an HPC background: It seems to be that with frequent rekeying the chance of successfully performing an exhaustive search attack is -- even for the most advanced adversary -- so slim that we do not need to worry about that. In reality this is a cost-for-computation tradeoff that no one is going to invest in if there're more practical ways to attack (e.g. HUMINT/bad OPSEC, steal a private key, intrude a given network etc.) given the resources and thus money/power needed.

> I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60 are all safe choices. If someone wants to rekey sooner (or often) for operational reason or any other reason, that would be ju…

...

> I am going to propose another option and I hope that you and all other people will be happy with.

I'd strongly suggest that any changes made to this text are as clear as possible to non-mathematicians/cryptographers. Years of dealing with TLS implementation and protocol vulnerabilities tell us that uncertain wording and missing, clear, explanation for certain choices in standards have caused real-world security problems. It seems to me that the general consensus is that option A is preferable anyhow.

Aaron

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Sat, 25 Feb 2017 14:28:40 +0000

Hi Sean, Joe, Eric and all,

I would like to address my thoughts/suggestions on 2 issues in option a.

1) The data limit should be addressed in term of blocks, not records. When the record size is not the full size, some user might not know what to do. When the record size is 1 block, the limit of 2^24.5 blocks (records) is way too low unnecessarily for the margin of 2^-60.  In that case, 2^34.5 1-block records is the limit which still achieves the margin of 2^-60.

2) To achieve the margin of 2^-57 as the current text says, the limit number should be 2^36 blocks.

Regards,

Quynh.

________________________________
From: Cfrg <[email-masked]> on behalf of Sean Turner <[email-masked]>
Sent: Friday, February 10, 2017 12:07 AM
To: <[email-masked]>
Cc: IRTF CFRG
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

All,

J&S