Skip to main content

Last Call Review of draft-ietf-tls-rfc8446bis-11
review-ietf-tls-rfc8446bis-11-genart-lc-hares-2024-11-15-00

Request Review of draft-ietf-tls-rfc8446bis
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-11-01
Requested 2024-10-18
Authors Eric Rescorla
I-D last updated 2024-11-15
Completed reviews Secdir Last Call review of -11 by Yoav Nir
Genart Last Call review of -11 by Susan Hares
Assignment Reviewer Susan Hares
State Completed
Request Last Call review on draft-ietf-tls-rfc8446bis by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/_vNWZvYNLv5itRAdMh1cneqMQAA
Reviewed revision 11
Result Ready w/nits
Completed 2024-11-15
review-ietf-tls-rfc8446bis-11-genart-lc-hares-2024-11-15-00
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.  /