Subject: [TLS] TLS 1.3 and max_fragment_length

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Mar 2017 14:38:14 +1100

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.)

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Mar 2017 10:06:07 +0200

> 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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Mar 2017 11:10:54 +0200

> On 14 Mar 2017, at 5:38, Martin Thomson <[email-masked]> wrote:
> 

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Mar 2017 13:04:44 +0200

On Tue, Mar 14, 2017 at 11:10:54AM +0200, Yoav Nir wrote:
> 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.

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Mar 2017 13:26:19 +0200

> can receive the record into 529 byte buffer and decrypt in

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 14 Mar 2017 15:44:03 -0500

>    applies to the full plaintext, including the padding.

That's probably fine, but maybe this one is better:

NEW:

   the maximum fragment length is reduced, such as by the 

   max_fragment_length extension from [RFC6066], then the reduced limit 

-Ben

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Mar 2017 08:27:41 +1100

>    applies to the full plaintext, including the padding.

Sounds good, I've created a PR.  I also changed the "may" to a  "MUST"
on the basis that this is an interoperability requirement.

https://github.com/tlswg/tls13-spec/pull/909