On 5/24/16, 12:58 PM, "ilariliusva...@welho.com on behalf of Ilari Liusvaara" <ilariliusva...@welho.com> wrote:
>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). I don¹t think so. > >> 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. True. > >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). I did not recommend using short random nonces. If the current construction of nonces is for GCM, than that would be fine and recommended. But, currently, it is written as for all ciphers. If the construction of nonce is not fixed, then an encryption mode just needs to specify its own way of generating nonces. > >And TLS breaks in truly catastrophic way if GCM nonce ever >repeats (and wasn't there just such problem in multiple TLS See comment above. >implmenentations)? > > >-Ilari Quynh. > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
