Re: [TLS] TLS 1.3 and max_fragment_length

[Yoav Nir <[e-mail]>]

> On 14 Mar 2017, at 5:38, Martin Thomson <[e-mail]> 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.
> 
> (BTW, RFC 6066 is quite poor.  It's not very precise in identifying
> what it is talking about, it also describes a negotiation design
> unlike anything else in TLS, one that can't be extended ever.)

Well, I can’t think of a single rational argument in favor of it *not* including the padding, so I guess I agree that it does.

If it didn’t include the padding, then any record with length greater than the max_fragment_length would be obviously padded. Why leak that?

Yoav