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" _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
