Subject: [TLS] Eric Rescorla's Yes on draft-ietf-tls-record-limit-02: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sat, 31 Mar 2018 12:31:56 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-tls-record-limit-02: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/

----------------------------------------------------------------------
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"