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