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

[Ballot comment]
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?

[Ballot comment]
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...".

[Ballot comment]
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.

[Ballot comment]
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"

[Ballot comment]
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"/

The following Last Call announcement was sent out (ends 2018-03-20):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-record-limit@ietf.org, Sean Turner , Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org, sean@sn3rd.com, tls-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: EXTENDED Last Call:  (Record Size Limit Extension for Transport Layer Security (TLS)) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Record Size Limit Extension for Transport
Layer Security (TLS)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  An extension to Transport Layer Security (TLS) is defined that allows
  endpoints to negotiate the maximum size of protected records that
  each will send the other.

  This replaces the maximum fragment length extension defined in RFC
  6066.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ballot/


No IPR declarations have been submitted directly on this I-D.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-tls-record-limit-02. If any part of this review is inaccurate, please let us know.

We understand that upon approval of this document, two registry actions must be performed. However, the second action and part of the first depend on the approval of another document.

First, the following entry will be added to the ExtensionType Values registry at

https://www.iana.org/assignments/tls-extensiontype-values

Value: TBD
Extension Name: record_size_limit
Reference: [this document]

After the new columns are added by draft-ietf-tls-iana-registry-updates, which has not yet been approved, the entry for the "Recommended" column will be "Yes," and the "TLS 1.3" column will be marked "Encrypted."

Second, after draft-ietf-tls-iana-registry-updates is approved and creates the "Recommended" column in that registry, the "Recommended" column for "max_fragment_length" will be marked "No."

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-03-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-record-limit@ietf.org, Sean Turner , Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org, sean@sn3rd.com, tls-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Record Size Limit Extension for Transport Layer Security (TLS)) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Record Size Limit Extension for Transport
Layer Security (TLS)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  An extension to Transport Layer Security (TLS) is defined that allows
  endpoints to negotiate the maximum size of protected records that
  each will send the other.

  This replaces the maximum fragment length extension defined in RFC
  6066.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Sean Turner is the document shepherd.
Kathleen Moriarty is the responsible Area Director.

This draft defines a TLS extension to negotiate the maximum size of protected records that each peers sends.  This mechanism replaces the maximum fragment length extension defined in RFC 6066.  It’s standards track because it updates RFC 6066, which is a PS.

2. Review and Consensus

The draft was very well received by the WG, resulting in minimal, minor comments.  There were two threads that contain all of the WG mailing list traffic related to this draft:
https://mailarchive.ietf.org/arch/msg/tls/l700Sq2m5nJDRfaS1VPk8w9sHKg
https://mailarchive.ietf.org/arch/msg/tls/tRwQqjH0-nqZec_9BTa97AfDsd8
Unlike other TLS-related topics, this WG settled on a solution quickly and consensus was very easily found.


3. Intellectual Property

Martin confirmed his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

4. Other Points

N/A