The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-rfc8446bis-14

# Internet AD comments for draft-ietf-tls-rfc8446bis-12
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S4.2.11.2

* "which may or may match" -> "which may or may not match"?

I have reviewed the changes with respect to RFC 8446. Thank you for this update! 

I'd suggest looking at the whole I-D for the phrase "in order" to ensure that no ambiguity could be intoduced by reading this as an sequence ordering requirement, rather than a logical condition in the writing style. In at least one place I was unsure: e.g., I wonder if /though endpoints are able to pad TLS records in order to obscure lengths/ is better as /though endpoints are able to pad TLS records to obscure lengths/ or /though endpoints are able to obscure lengths by padding TLS records/.

When looking at the idnits tool there are quiet a number of messages to look at, and not fully explained in doc shepherds writeup

Thanks to the authors, contributors, and the WG for the work on this important document.

I have the following comments/suggestions to offer on this document.

1) In the abstract ... and this is assuming that this document is not actually obsoleting 8422 ...

CURRENT
This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations.

SUGGEST
This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFC 8446. This document also specifies new requirements for TLS 1.2 implementations.

2) Please state in the introduction section on what part of 8422 is being updated by this document.

3) RFCs 5077, 5246 and 6961 were actually obsoleted by RFC 8446 and not this document. Please rephrase some of the references to those documents saying that they were obsoleted by RFC 8446 and not "this document".

4) Ref section 1.4 - does this document also not update RFC7627 with its terminology change?

5) I found the IANA consideration section hard to follow in terms of clarity on what exactly is the action for IANA team from this document. Section 11.1 has clear actions but the parent section 11 is perhaps having some remnant actions from RFC8446 that might be confusing. If all that the section 11 talks about is something that IANA has already done, perhaps simply a description of the IANA registries pertaining to this document (previously pertaining to RFC8446) without talking about any action that was done or to be done would be more clear? And then there is 11.1 for the actual IANA work/actions to be done?

6) I believe there is an error with the reference to RFC8444. That one is a OSPF routing protocol extension and don't see how that comes into TLS land.

Thanks for this clean and well-written revision. I have only a few minor observations which can be incorporated at the discretion of the author and the responsible AD:
===

In the list of diffs, one of the bullets appears to be two changes. Should these be separate bullets, or should a sentence be added before these two explaining how they're connected?

>Restore text defining the level of "close_notify" to "warning".	
>Clarify behavior around "user_canceled", requiring that	
>"close_notify" be sent and that "user_canceled" should be ignored.

===

The language around the SCSV for pre-1.2 values feels odd. You MUST NOT negotiate older versions, but if you do anyway, you MUST do it this way? I would shift this to a description of how clients and servers were required to behave prior to this revision of 1.3 at most.

===

CURRENT: select a group based "supported_groups" 

CONSIDER: select a group based on "supported_groups"

===

OLD: For X25519 and X448, the contents of the public value are the byte string inputs and outputs of the corresponding functions....

CURRENT: For X25519 and X448, the contents of the public value is the K_A or K_B value....

CONSIDER: For X25519 and X448, the content of the public value is the K_A or K_B value....

Hi Eric, 

Thanks for the effort put into the maintenance of this key specification. 

I reviewed only the diff vs. RFC8446. Please find below some few comments, most are nits: 

# No need to obsolete already obsoleted RFCs (RFCs 5077, 5246, 6961, 8422). Likewise, I didn’t find new updates of 5705 and 6066 beyond what was already updated by RFC8446.

CURRENT:
   This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
   RFCs 5077, 5246, 6961, 8422, and 8446.  This document also specifies
   new requirements for TLS 1.2 implementations.

# (nit) Introduction: “application protocols ..with their application protocol” 

OLD: 
Application protocols using TLS
   MUST specify how TLS works with their application protocol, including
   how and when handshaking occurs, and how to do identity verification.

Maybe 

NEW:
   Applications using TLS
   MUST specify how TLS works with their application protocol, including
   how and when handshaking occurs, and how to do identity verification.

# (nit) 4.2.8: omission and inclusion

OLD:
   For this reason, the omission of a share for group A and inclusion of
   one for group B does not mean that the client prefers B to A.

NEW:
   For this reason, the omission of a share for group A and inclusion of
   one for group B do not mean that the client prefers B to A.

# (nit) 4.2.8.1

OLD: the contents of the public value is
NEW: the contents of the public value are

# (nit) Section 11: please double check this sentence:

CURRENT:
The changes
   between [RFC8446] and [RFC8447] this document are described in
   Section 11.1.  IANA has updated these to reference this document.

Cheers,
Med

Thank you to Susan Hares for the GENART review.

After reviewing only the diffs from RFC 8446 (and there is nearly no intersection with the INT area).