On Tue, Mar 14, 2017 at 02:38:14PM +1100, Martin Thomson wrote: > When we added padding to TLS 1.3, we created an ambiguity with the > max_fragment_length extension. > > Does the limit apply to len(TLSInnerPlaintext) or does it apply to > len(TLSInnerPlaintext.content) (i.e., TLSPlaintext.length)? That is, > does is include the padding and content type, or not? > > Including the padding would recognize the limitations apply to > handling large blobs of encrypted data (see earlier email from Thomas > Pornin). That would be my preference. I think that we need to say > that though. I guess the second-order question is whether to roll > RFC6066-bis or patch these things in TLS 1.3 directly.
I would think it would include the padding, because otherwise you can not limit the size of buffers to store a record. And if you have an encrypted record, you can decrypt it in-place anyway, so limits on plaintext size post-depadding are not useful. Furthermore, there is edge case in how max_fragement_length is currently defined in TLS 1.3 (it isn't available when parsing ServerHello, but ServerHello is also limited by it). Fortunately, that edge case is very unlikely to be hit, as ServerHello is highly likely to be under the limit[1], and ServerHello can't be coalesced with anything (since it has flight or key boundaries on both sides). [1] Base ServerHello is 42 bytes, pre_shared_key gives you 6. And key_share gives you 8+size_of_share. So at maximum you have 56+ size_of_share. The minimum limit is 512, and to reach that you need 456 byte share. The only things that have shares of that size are groups 258, 259 and 260. And none of those would seem to be likely implemented by any device that uses max_fragment_length. For 1024-byte limit, you have 968 bytes, which is only exceeded by group 260. And for higher 2048 and 4096 byte limits, no current group is big enough to blow the size limits. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
