Reviewer: Susan Hares Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-tls-rfc8446bis-?? Reviewer: Susan Hares Review Date: 2024-11-15 IETF LC End Date: 2024-11-01 IESG Telechat date: Not scheduled for a telechat Caveat: Prior to reading this, I had not read RFC8446. Summary: The author of this draft (Eric Rescorla) should be commented for the amazing amount of careful work on this bis draft. This draft provides exhaustive details written. The draft is carefully written to include everything an implementer needs. The appendices are a gold-mine of really useful information. Caveat: I do not have the history on RFC8446, and I have not implemented TLS 1.2 or 1.3. Take my opinion as a casual reader. I suspect the IETF chair is familar with this technology. Major issues: None Minor issues: None - all messages, state transitions, and variables seem to be clearly discussed (AFIK) Nits/editorial comments: NIT-1: One confusing nit is the usage of ";" in the following locations. The definition of ";" according to scholarly writing for the usage of (clause-1);(clause-2) is that the clauses are equivalent. In the following cases I cannot find this equivalence: 1.1 Section 1. paragraph 3 (or 4) Text:/The handshake protocol is designed to resist tampering; an active attacker should not be able to force the peers to negotiate different parameters than they would if the connection were not under attack./ 1.2. Section 1, paragraph 4 (or 5) Text:/The TLS standard, however, does not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. / 1.3. Section 1.3, paragraph 1, Text:/ * Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy./ 1.4. Section 4.2.7, last paragraph Text:/ If the server has a group it prefers to the ones in the "key_share" extension but is still willing to accept the ClientHello, it SHOULD send "supported_groups" to update the client's view of its preferences; this extension SHOULD contain all groups the server supports, regardless of whether they are currently supported by the client./ 1.5. Section 4.2.9, paragraph 2, last sentence Text:/ Servers SHOULD NOT send NewSessionTicket with tickets that are not compatible with the advertised modes; however, if a server does so, the impact will just be that the client's attempts at resumption fail./ 1.6. Section 4.6.1, paragraph 4 (or 5) Text:/The latter is a performance optimization: normally, there is no reason to expect that different servers covered by a single certificate would be able to accept each other's tickets; hence, attempting resumption in that case would waste a single-use ticket. / 1.7. Section 5.3, paragraph 1 text:/ Each sequence number is set to zero at the beginning of a connection and whenever the key is changed; the first record transmitted under a particular traffic key MUST use sequence number 0./ 1.8. Secxtion 5.4, paragraph 3 Text:/Implementations MUST NOT send Handshake and Alert records that have a zero-length TLSInnerPlaintext.content; if such a message is received, the receiving implementation MUST terminate the connection with an "unexpected_message" alert./ 1.9. Section 8 paragraph 3 1.9.1) Text:/ The server MUST ensure that any instance of it (be it a machine, a thread, or any other entity within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once; this limits the number of replays to the number of server instances in the deployment./ 1.9.2) Text:/ The "at most once per server instance" guarantee is a minimum requirement; servers SHOULD limit 0-RTT replays further when feasible./ 1.10) Section 8.3, paragraph 4/5 text:/ For clients on the Internet, this implies windows on the order of ten seconds to account for errors in clocks and variations in measurements; other deployment scenarios may have different needs./ NIT2: Too many comments in a sentence 2.1. Section 1.3, paragraph 1 Text:/ * Elliptic curve algorithms are now in the base spec, and new signature algorithms, such as EdDSA, are included./ In my reading of grammar, the first comma is not needed. Its inclusion makes the ", such as EdDSA," confusing. 2.2. Section 4.4.1, paragraph 5 It may be that you are just missing an "and". Text: / For concreteness, the transcript hash is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, server CertificateRequest, server Certificate, server CertificateVerify, server Finished, EndOfEarlyData, client Certificate, client CertificateVerify, client Finished./ You may be just missing and before "client Finished." 3. Use of text offset by -- (text) --- 3.1. Section 4.6.3, last paragraph /In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch -- and hence the number of key updates -- to exceed 2^48-1. In order to allow this value to be changed later -- for instance for ciphers with more than 128-bit keys -- receiving implementations MUST NOT enforce this rule. / 3.2. Section 5.4, paragraph 6 Text:/ If the maximum fragment length is reduced -- as for example by the record_size_limit extension from [RFC8449] -- then the reduced limit applies to the full plaintext, including the content type and padding./ 3.3. Section 8.3, last paragraph Text:/ Note that freshness checking alone is not sufficient to prevent replays because it does not detect them during the error window, which -- depending on bandwidth and system capacity -- could include billions of replays in real-world settings. / -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
