Re: [TLS] RFC 6066 - Max fragment length negotiation

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 17, 2017 at 11:21:12AM +0000, Peter Gutmann wrote:
> Martin Thomson <[e-mail]> writes:
> 
> >Plaintext records don't have any such limits.  I explicitly excluded them.
> 
> Hmm, it's somewhat disguised in the text, technically all records are
> "protected records" (if you use EMS, everything is at least integrity-
> protected).  So if you mean "this only applies to application_data" then you
> should probably say so (alerts and CCS are too short for it to matter, and I'm
> assuming no rehandshake, so only application_data will be affected by the
> length constraints).

I think Martin said the only case where this special case comes into play
is renegotiation?
 
> However, this then leads to a problem where it doesn't actually solve the
> constrained-client/server issue, if a client asks for 2K max record size and
> the server responds with a 4K hello then it's going to break the client even
> if later application_data records are only 2K.  So it would need to apply to
> every record type, not just application_data.

I don't think responding with 2k ServerHello is even possible in TLS
1.3 as defined. Even group 260 would push the size slightly above 1k
And I don't think 1k is even reachable without that group.

In fact, in TLS 1.3, all messages except Certificate ones are likely to
be under 2k (or 1k). Of course, multiple can be combined into a record.

TLS 1.2 ServerHellos can be larger, but this is mostly connected with
certain extensions, like signed_certificate_timestamp. There are also
some messages that can be bit bigger, like certificate_status or
server_key_exchange.


-Ilari