Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
draft-ietf-uta-rfc7525bis-11

Many thanks to Cullen Jennings for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/mTDKkYaQC44xMGxfdw4zKt3_e1o/.

# SEC AD review of draft-ietf-uta-rfc7525bis-09

CC @paulwouters

Thanks for this document. It is a great collection of security advise to follow.

Thank you to Ben Kaduk for the SECDIR review.

** Section 3.2
  When TLS-only	
  communication is available for a certain protocol, it MUST be used	
  by implementations and MUST be configured by administrators.

This guidance seems a little vague but prescriptive.  Is the guidance that if there is a TLS-version or TLS support for a given protocol, that implementations of that protocol “MUST” support it?  My confusion is around the wording that “it must be used by implementations.”

** Section 3.2
	When	
	a protocol only supports dynamic upgrade, implementations MUST	
	provide a strict local policy (a policy that forbids use of	
	plaintext in the absence of a negotiated TLS channel) and	
	administrators MUST use this policy.

Aren’t site administrators responsible for setting and enforcing local policy?  Why would the software vendor (implementations) be provided the policy?

** Section 3.3.1

-- Given that the recommendations of this section include things beyond certificate compression, is the title of “Certificate Compression” appropriate?

-- Would there be any additional techniques to list per Section 4 of RFC9191?

** Section 4.4
	When a sender is approaching CL, the implementation SHOULD initiate a	
	new handshake (or in TLS 1.3, a Key Update) to rotate the session	
	key.	
		 		
	When a receiver has reached IL, the implementation SHOULD close the	
	connection.

Should these normative SHOULDs be MUSTs?  What is the circumstance where it would be prudent or necessary sender to use the existing key material after the CL has been exceeded?  Same issue on the IL limit.

I suspect that I'm being dumb, but I cannot quite reconcile:

* Implementations MUST NOT negotiate SSL version 3.
* Implementations MUST NOT negotiate TLS version 1.0 [RFC2246].
* Implementations MUST NOT negotiate TLS version 1.1 [RFC4346].
with:
* Implementations MUST support TLS 1.2 [RFC5246] and **MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS** (emphasis added).

I don't understand the last part -- it seems like this equates to:
{
if (version == SSL3 || version == TLS1 || version == TLS1.1 ) { abort(); }
if (version >= 1.2) { do_stuff () }; 
}
I don't understand the "if (version >= 1.2)" check -- if I MUST NOT use SSL3, TLS1.0, TLS1.1, then isn't the only thing left >= TLS 1.2?
Not trying to be difficult, I really just don't understand what I'm missing...

Thanks for working on this specification. It is certainly be useful.

Thanks to Magnus Westerlund for his TSVART review, which is done in a very short notice. Please treat his review comments as if those are mine.

# GEN AD review of draft-ietf-uta-rfc7525bis-09

CC @larseggert

Thanks to Tim Evens for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/Cm6WU_TE-rTbHuLT1WLLc26vrl0).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 6
```
-    implementations, assuming the implementer expects his or her code to
-                                                      ^^^^^^^
+    implementations, assuming the implementer expects their code to
+                                                      ^  +
```

### Duplicate references

Duplicate informative references to: `rfc7672`.

### Outdated references

Reference `[RFC8740]` to `RFC8740`, which was obsoleted by `RFC9113` (this may
be on purpose).

Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may
be on purpose).

Reference `[RFC6347]` to `RFC6347`, which was obsoleted by `RFC9147` (this may
be on purpose).

Reference `[RFC4346]` to `RFC4346`, which was obsoleted by `RFC5246` (this may
be on purpose).

Reference `[RFC4347]` to `RFC4347`, which was obsoleted by `RFC6347` (this may
be on purpose).

Reference `[RFC6961]` to `RFC6961`, which was obsoleted by `RFC8446` (this may
be on purpose).

Reference `[RFC2246]` to `RFC2246`, which was obsoleted by `RFC4346` (this may
be on purpose).

Reference `[RFC5077]` to `RFC5077`, which was obsoleted by `RFC8446` (this may
be on purpose).

Reference `[RFC7507]` to `RFC7507`, which was obsoleted by `RFC8996` (this may
be on purpose).

### URLs

These URLs in the document did not return content:

 * https://www.cabforum.org/documents.html

### Grammar/style

#### Section 1, paragraph 7
```
rabilities than TLS 1.2 or below. Therefore this document replaces [RFC7525],
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 1, paragraph 8
```
n and deployment scenarios, with the exception of unauthenticated TLS (see S
                            ^^^^^^^^^^^^^^^^^^^^^
```
Consider using "except" or "except for".

#### Section 3.1.1, paragraph 11
```
is significantly easier and less error prone than secure deployment of TLS 1
                                 ^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 3.3.1, paragraph 4
```
used when encrypting the ticket (as least as strong as the main TLS cipher su
                                    ^^^^^
```
Did you mean "less", "little"? Or "at least"?

#### Section 3.9, paragraph 1
```
h the server and the client side. Typically this extends to both the TLS libr
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Typically".

#### Section 4.2, paragraph 6
```
l interoperability, except with extremely old clients. As with other cipher
                                ^^^^^^^^^^^^^
```
Consider using an extreme adjective for "old".

#### Section 4.4, paragraph 3
```
ther demonstrates that 1024-bit Diffie Hellman parameters should be avoided.
                                ^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 4.4, paragraph 8
```
 cipher suites recommended above. However it does apply to most other TLS ci
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### Section 5.1, paragraph 9
```
s discovered indirectly and in an insecure manner (e.g., by an insecure DNS q
                            ^^^^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "insecurely" to avoid wordiness.

#### Section 5.2, paragraph 1
```
 AES-GCM getting implemented in an insecure way and thus making TLS sessions
                             ^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "insecurely" to avoid wordiness.

#### Section 7.3, paragraph 12
```
n database cannot scale beyond a small number of the most heavily used Web se
                               ^^^^^^^^^^^^^^^^^
```
Specify a number, remove phrase, use "a few", or use "some".

#### Section 7.4, paragraph 5
```
o the CertificateEntry structure. However using this facility remains imprac
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### Section 7.5, paragraph 1
```
lient authentication, but we recommend to review the operational conditions b
                             ^^^^^^^^^^^^^^^^^^^
```
The verb "recommend" is used with the gerund form.

## 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. Review generated by the [`ietf-reviewtool`][IRT].

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

Thank you for accommodating the concerns that I raised in my discuss.

Regards,
Rob