# Internet AD comments for draft-ietf-uta-require-tls13-06
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/

## Comments

### S4

* "When the API allows it, clients SHOULD specify just the minimum version
   they want."

  I struggled with this phrasing and attempting to reconcile it with the
  broader goal of requiring TLS1.3.  What is really meant here, and could
  it be more clearly stated?

## Nits

### S5

* "At this time it was published" ->
  "At the time it was published"

Worth clarifying throughout that protocols *which use TLS* must use TLS 1.3 (or later). This document isn't (I believe) attempting to mandate that all protocols use TLS in all contexts.

Section 5, the "small changes" are small by text size, but substantial in impact. Referring to the changes as "small" seems unnecessary.

Thanks Rich for this document.

Thanks also to Samier for his first opsdir review.

I fully support. Some clarity is needed to unambiguously characterize which "new protocols" we are covering. A fix for this and other edits were shared with Rich using a PR. I'm removing that link and include the changes in the ballot itself.

Apologies for the inconvenience.

# Title

## Clarify this is for TLS-based protocols

OLD: "New Protocols Must Require TLS 1.3"
NEW: "New Protocols with TLS Support Must Require TLS 1.3"

# Section 1

## Clarify this is for TLS-based protocols

OLD: For these reasons, new protocols must require and
NEW: For these reasons, new protocols with TLS support must require and

## minor edit

OLD: Note that addressing them usually requires bespoke configuration.
NEW: Addressing them usually requires bespoke configuration.

## minor edit

OLD: 
  removing most cryptographic primitives considered dangerous. Importantly, TLS
  1.3 enjoys robust security proofs and provides excellent security without
  any additional configuration.

NEW:
  removing most cryptographic primitives considered dangerous. Importantly, compared to TLS1.2, TLS
  1.3 provides better security without any additional configuration.


## Clarify this is for TLS-based protocols

OLD: This document specifies that, since TLS 1.3 use is widespread, new protocols
NEW: This document specifies that, since TLS 1.3 use is widespread, new protocols with TLS support


# Section 3

## nit

OLD: Implications for post-quantum cryptography
NEW: Implications for Post-Quantum Cryptography (PQC)


## clarify impact + nits

OLD:
  have a huge impact on TLS traffic. To mitigate this, TLS applications
  will need to migrate to post-quantum cryptography (PQC) [PQC].
  Detailed consideration of when any application requires PQC, or when
  a CRQC is a threat they need to protect against, is beyond the

NEW:
  have a huge impact on TLS traffic (see, e.g., Section 2 of [I-D.ietf-pquip-pqc-engineers]). To mitigate this, TLS applications
  will need to migrate to Post-Quantum Cryptography (PQC) [PQC].
  Detailed considerations of when an application requires PQC or when
  a CRQC is a threat that an application need to protect against, are beyond the


## nit

OLD: For TLS it is important to note that the focus of these efforts is TLS 1.3
NEW: It is important to note that the focus of these PQC efforts for TLS is TLS 1.3


## Clarify this is for TLS-based protocols

OLD: This is one more reason for new protocols to default to TLS 1.3, where
NEW: This is one more reason for new protocols requiring TLS service to default to TLS 1.3, where

# Section 4


## nit

OLD: then clients SHOULD specify just the minimum
NEW: then clients SHOULD specify the minimum


# Section 5

## nit

OLD: RFC 9325 provides recommendations for ensuring the security of deployed
NEW: [RFC9325] provides recommendations for ensuring the security of deployed


## nit

OLD:
  At the time it was published, it described availability of TLS 1.3
  as "widely available." The transition and adoption mentioned in that
  documnent has grown, and this document now makes two small changes

NEW:
  At the time it was published, it described availability of TLS 1.3
  as "widely available". The transition and adoption mentioned in that
  document has grown, and this document now makes two small changes

## clarify this is for tls-based protocols

OLD: 
  That section says that TLS 1.3 SHOULD be supported; this document says
  that for new protocols it MUST be supported.

NEW:
  That section says that TLS 1.3 SHOULD be supported; this document mandates
  that TLS 1.3 MUST be supported for new TLS-based protocols.

## nit

OLD: 
  That section says that TLS 1.2 MUST be supported; this document says that
  it MAY be supported as described above.

NEW:
  That section says that TLS 1.2 MUST be supported; this document says that
  TLS 1.2 MAY be supported.

# Section 6

## nit

OLD: See [I-D.draft-ietf-tls-deprecate-obsolete-kex] for details.
NEW: See [I-D.ietf-tls-deprecate-obsolete-kex] for details.

## nit

OLD: years exploiting CBC cipher suites; refer to e.g. [CBCSCANNING]
OLD: years exploiting CBC cipher suites; refer to, e.g., [CBCSCANNING]

Cheers,
Med

# Éric Vyncke, INT AD, comments for draft-ietf-uta-require-tls13-10

CC @evyncke

Thank you for the work put into this document. It is always useful to stress the important security standards.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Valery Smyslov for the shepherd's write-up including the WG consensus ***but it lacks*** the justification of the intended status.

Other thanks to Scott Rose, the DNS directorate reviewer, please consider this int-dir review and one typo:
https://datatracker.ietf.org/doc/review-ietf-uta-require-tls13-10-dnsdir-telechat-rose-2025-03-27/ (and I have read reply)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Title

Should the title be "At Least v1.3 of TLS" ?

### Abstract

The sentence about example does not really fit an abstract, please remove.

Unsure how to read `fixed weaknesses in TLS 1.2` ? I.e, if they are fixed, then why move to TLS 1.3 ?

### Section 1

The first paragraph is somehow self-contradicting "good security properties" vs. "several deficiencies" vs. "bespoke configuration".

### Section 4

I would remove the DoT counter-example, it is only confusing.

Isn't the set of crypto algorithms also part of the negotiation ? I.e., a 'stupid' configuration could have TLS 1.2 with really good crypto and TLS 1.3 with average one (in a couple of years). Should the text mention this as well ?

### Section 6

While this section proposes mitigations to some attacks against TLS 1.2, it does not do so for *all* attacks while section claims that bespoke configuration can fix all weaknesses of TLS 1.2.