Re: [TLS] TLS 1.3 and max_fragment_length

[Yoav Nir <[e-mail]>]

On 14 Mar 2017, at 13:04, Ilari Liusvaara <[e-mail]> wrote:

> On Tue, Mar 14, 2017 at 11:10:54AM +0200, Yoav Nir wrote:
>> 
>>> 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?
> 
> Actually, even worse, then the padding would require extra memory,
> which the endpoint presumably does not have.
> 
> If you limit padded plaintext length to 513 bytes (the minimum
> needed for 512 byte plaintext), with current ciphers, the record
> payload is at most 529 bytes (16 byte tag is added). Thus, you
> can receive the record into 529 byte buffer and decrypt in
> place.
> 

Seems we’re in agreement. So how about modifying the sixth paragraph in section 5.4?

OLD:
   The presence of padding does not change the overall record size
   limitations - the full fragment plaintext may not exceed 2^14 octets.

NEW:
   The presence of padding does not change the overall record size
   limitations - the full fragment plaintext may not exceed 2^14 octets. If
   the maximum fragment length is reduced by the presence of the
   max_fragment_length extension from [RFC6066] then the reduced limit
   applies to the full plaintext, including the padding.


Yoav