Skip to main content

Record Size Limit Extension for TLS
draft-ietf-tls-record-limit-03

Yes

(Alexey Melnikov)
(Ben Campbell)
(Benjamin Kaduk)
(Terry Manderson)

No Objection

(Alissa Cooper)
(Deborah Brungard)
(Ignas Bagdonas)
(Suresh Krishnan)

Note: This ballot was opened for revision 02 and is now closed.

Warren Kumari
No Objection
Comment (2018-04-02 for -02) Unknown
Thanks to Éric Vyncke for his OpsDir review of this document.
Adam Roach Former IESG member
Yes
Yes (2018-04-03 for -02) Unknown
Thanks to everyone who contributed work towards this document.

---------------------------------------------------------------------------

§4:

>  MUST NOT send a value higher than the protocol-defined maximum record
>  size unless explicitly allowed by such a future version or extension.

Presumably, recipients MUST gracefully accept values higher than the maximum
record size?  That is implied by this text (and the text that follows), but
given how TLS frequently aborts connections at the first sign of any
irregularity, it's probably worth saying explicitly.

---------------------------------------------------------------------------

§4:

>  a DTLS endpoint that
>  receives a record larger than its advertised limit MAY either
>  generate a fatal "record_overflow" alert or discard the record.

I'm concerned about the interaction between the option to discard the record and
protocols that perform retransmission of lost packets over DTLS (e.g., proposals
such as draft-rescorla-quic-over-dtls). In the case that an oversized packet is
simply discarded, retransmissions of that (presumably still oversized) packet
will take a while to time out (I'm not particularly well-versed in QUIC, but
assume it has characteristics similar to TCP's ~nine-minute timeout), which
would result in really bad user experiences.  Is there rationale for this optionality?
It would seem to be cleaner if the response were simply to always send a fatal
error.

If this optionality is retained, please at least consider adding text describing
the impact of discarding oversized packets when used with a reliable protocol.

---------------------------------------------------------------------------

§4.1:

>  In TLS 1.2, block ciphers allow between 1 and 256 octets of padding.

nit: The formulation "between X and Y" is ambiguous as to whether X and Y are
included in the range. Consider rephrasing as "...from 1 to 256...".
Alexey Melnikov Former IESG member
Yes
Yes (for -02) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (for -02) Unknown

                            
Benjamin Kaduk Former IESG member
Yes
Yes (for -02) Unknown

                            
Eric Rescorla Former IESG member
Yes
Yes (2018-03-31 for -02) Unknown
I apologize for not catching the point about "negotiated" earlier.


   An Authentication Encryption with Additional Data (AEAD) ciphers (see
   [RFC5116]) API requires that an entire record be present to decrypt
Nit: "An" .. "ciphers" do not agree.



   incremental processing of records minimally exposes endpoints to the
   risk of forged data.
This seems a bit weak. It's just not an acceptable practices to incrementally process.



   Unprotected messages - handshake messages in particular - are not
   subject to this limit.
This text is a bit confusing. Consider a case where a server recognizes the extension and has no limit, but the client offers one.

In that case, the server can either:

Return an extension with a max-size limit
Not return the extension
I think we want the server to conform to the client's limit in any case, but "negotiated" is unclear.


   they have no need to limit the size of records.  This allows servers
   to apply a limit at their discretion.  If this extension is not
   negotiated, endpoints can send records of any size permitted by the
I think by "apply" you mean "request" or "advertise"
Terry Manderson Former IESG member
Yes
Yes (for -02) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (2018-04-05 for -02) Unknown
Hello, I'm not a TLS expert so please disregard if this is irrelevant.
Document says:
   Clients that depend on having a small record size MAY continue to
   advertise the "max_fragment_length".

Do you mean:
   Clients that depend on having a small record size MAY continue to
   advertise the "max_fragment_length" *only*.

If so, what would be the behaviour of a server that supports both "max_fragment_length" and "record_size_limit" in that situation?
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-03-29 for -02) Unknown
Thanks for the well written doc!

One minor comment the title of sec 5: not sure if "deprecating" is the best word as that maybe be read as "moved to historic" in IETF world...

Tiny typo in sec 5:
s/and "max_fragment_length"/an "max_fragment_length"/
Spencer Dawkins Former IESG member
No Objection
No Objection (2018-04-02 for -02) Unknown
This is a nit, but just to make sure …

  The "record_size_limit" extension replaces the "max_fragment_length"
   extension [RFC6066].  A server that supports the "record_size_limit"
   extension MUST ignore and "max_fragment_length" that appears in a
                         ^^^
the "and" should be "any", shouldn't it?

   ClientHello if both extensions appear.  A client MUST treat receipt
   of both "max_fragment_length" and "record_size_limit" as a fatal
   error, and SHOULD generate an "illegal_parameter" alert.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -02) Unknown