Re: Review (Re: [TLS] I-D ACTION:draft-ietf-tls-ctr-00.txt)

nagendra modadugu wrote:
>>On the block level counter, 3686 specifies a 32-bit counter citing
>>IPv6 Jumbograms' requirement.  SRTP makes a note that for multimedia
>>apps, that might be safely ignored.  Could you also make a similar
>>note in this document, or perhaps you might also want to support
>>jumbograms?  (Perhaps IPv6 historians might tell us whether there are
>>practical uses for jumbograms).
> 
> The limit on the counter here is to support a TLS record of 2^14 octets.

2^14 octets is the "maximum fragment length" (TLSPlaintext.length).
The maximum length of the input to encryption (TLSCompressed.length) is
is 2^14 + 1024 octets. See RFC2246[bis-13] sections 6.2.2 and 6.2.3.
Fragment length negotiation allow these limits to be decreased, but not
increased.

>From section 3.1.1 of the draft:

   Note that the block counter does not overflow since the maximum TLS/
   DTLS record size is 14 KB and 16 bits of blk_ctr allow the generation
   of 1MB of keying material per record.

The property needed is that 2^14 + 1024 octets <= (128/8) * 2^16 octets.
Also "KB" and "MB" should not be used in IETF documents; they are not
well-defined. So this paragraph should be:

   Note that the block counter does not overflow since the maximum
   size of input to the record payload protection layer in TLS or DTLS
   (TLSCompressed.length) is 2^14 + 1024 octets, and 16 bits of blk_ctr
   allow the generation of 2^20 octets (2^16 AES blocks) of keying
   material per record.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls