[Uta] Éric Vyncke's No Objection on draft-ietf-uta-rfc7525bis-09: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-uta-rfc7525bis-09: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Éric Vyncke, INT AD, comments for draft-ietf-uta-rfc7525bis-09
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Leif Johansson for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### No 7457bis ?

I find a little weird that the legacy 'attack' document, RFC 7457, is not
updated, but that the new attacks (the updated content of RFC 7457) are
described in this document. No hard feeling though, and thanks for the warning
text in section 1.

### Section 1

```
   Therefore this document replaces [RFC7525], with an explicit goal to
   encourage migration of most uses of TLS 1.2 to TLS 1.3.
```
Should it be stated with 'RECOMMEND' ?

### Section 1 what is meant by "stronger"

```
   Furthermore, this
   document provides a floor, not a ceiling, so stronger options are
   always allowed (e.g., depending on differing evaluations of the
   importance of cryptographic strength vs. computational load).
```

While the astute readers will understand what is meant by 'stronger', should
this document be clear on what is meant by 'stronger' in each subsequent
sections ?

### Section 3.1.1 what about SSLv1

While I am not familiar with old SSL, if there was a SSLv1, should this
document also have recommendation about SSLv1 ?

### Section 3.1.1 unclear

Perhaps because I am not a native English speaker, but I find this sentence
hard to parse: ```
      Even if a TLS
      implementation defaults to TLS 1.3, as long as it supports TLS 1.2
      it MUST follow all the recommendations in this document.
```

### Section 3.1.3 SCSV

It would not hurt expanding "SCSV" at first use even if a reference is added.

### Section 3.7 ESNI as a SHOULD ?

Shouldn't ESNI be a normative "SHOULD" ? Or is the non-normative text "just" to
avoid forming a cluster with ESNI draft ? Which would be sad...

### Section 4.1 post-quantum crypto

A little surprised by the absence of any "post-quantum crypto" reference in
this introduction text.

### Section 4.5 TWIRL ?

Should "TWIRL" be expanded ? or at least given a reference ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments