On Tue, May 24, 2016 at 03:20:17PM +0000, Dang, Quynh (Fed) wrote: > Hi Eric, > > 1. For this text: "plus the length of the output of the signing > algorithm. " in the last paragraph of Section 4.8.1, did you mean > "plus the output of the signing algorithm." ?
The paragraph seems to talk about the length, so plus length of seems correct. > 2. "The length (in bytes) of the following TLSCiphertext.fragment. > The length MUST NOT exceed 2^14 + 256. An endpoint that receives a > record that exceeds this length MUST generate a fatal "record_overflow" > alert. " . There could be a cipher that generates ciphertext longer > than plaintext in some cases plus the tag. If the tag was 256 bits, > then this requirement would disallow that cipher unnecessarily when > a record size is 2^14. It is not in bits, it is in bytes. So to blow the limit, you would need cipher that expands the plaintext by 256 bytes (remember the typebyte counts as plaintext input here). And what algorithm would have >2040 bits of expansion? Variable-tau MRAEs could have larger expansions, but practical parameters limit expansion much below that value. > 3. "The padded sequence number is XORed with the static client_write_iv > or server_write_iv, depending on the role." I think the ivs are not > needed. Oh, they are needed (as in, security will be degraded if IVs are removed). > 4. The current way nonce is specified would disallow ciphers that > use any other ways of generating the nonce such as random nonces. None of the present algorithms is able to handle a random nonce, you would need much longer nonces. And also, it is much easier to just count than try to randomly generate "nonces" (and as far as it is known, more secure, due to random "nonces" having tendency to repeat). And TLS breaks in truly catastrophic way if GCM nonce ever repeats (and wasn't there just such problem in multiple TLS implmenentations)? -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
