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 <cfrg-boun...@irtf.org> on behalf of Sean Turner <s...@sn3rd.com> Sent: Friday, February 10, 2017 12:07:35 AM To: <tls@ietf.org> Cc: IRTF CFRG Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) 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 _______________________________________________ Cfrg mailing list c...@irtf.org https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
