Re: [TLS] TLS 1.3 and max_fragment_length

[Ilari Liusvaara <[e-mail]>]

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