All fine.
Hilarie
--
----- Original Message -----
From: "Salz, Rich" <rsalz=40akamai....@dmarc.ietf.org>
To: "Hilarie Orman via Datatracker" <nore...@ietf.org>, "secdir"
<sec...@ietf.org>
Cc: "draft-ietf-uta-require-tls13 all"
<draft-ietf-uta-require-tls13....@ietf.org>, last-c...@ietf.org, uta@ietf.org
Sent: Wednesday, March 26, 2025 2:32:39 PM
Subject: [secdir] Re: Secdir last call review of draft-ietf-uta-require-tls13-06
Thanks for the review! Do the following changes address your concerns?
* The gist of the document is "use TLS 1.3", but I cannot tell what the
command is directed to. The title says "new protocols". Does that
mean "new protocols that require transport layer confidentiality,
integrity, and authentication"?? Any new protocol that specifies TLS?
Or simply any new protocol within the IETF? Section 1 says that it
updates Section 5 of RFC9325. but it's not clear if that is the sole
intent of this document, or if it has a wider scope.
The wording now says (in a couple of places) “protocols that use TLS”.
* "TLS 1.3 enjoys robust security proofs" sounds definitive, but I think
that might be misleading to the average reader. There has been a
great deal of attention paid to proving various cryptographic aspects
of the protocol, and some attention to implementation proofs, but
these fall short of being an ironclad guarantee that "this cannot fail in
practice". I don't think "robust" has any useful technical meaning
with regard to proofs. Some rephrasing might convey the idea that
"there has been a lot of careful scrutiny of the the protocol."
Changed to “Importantly, the protocol has had comprehensive security proofs and
should provide excellent security without any additional configuration. “
* Section 3 states "cryptographically-relevant quantum computers (CRQC),
once available, ..." raises our expectations for these devices.
Do they exist now, but they aren't "available" for cryptography?
Will they exist within the lifetime of anyone reading the document
now? It's highly debatable. I'd add a pinch more of the subjunctive
tense to this.
I think “once available” is good enough. Right now they can factor 15 and 21
without resorting to “trick” numbers. Nobody knows whewn a CRQC will be
available. I am going to leave it as-is.
* Section 6: "TLS 1.2 was specified with several cryptographic
primitives and design choices that have, over time, weakened its
security."
Changed to “become significantly weaker.”
Here’s a diff of the above-described changes.
$ g diff
diff --git a/draft-ietf-uta-require-tls13.md b/draft-ietf-uta-require-tls13.md
index bdab073..119bec7 100644
--- a/draft-ietf-uta-require-tls13.md
+++ b/draft-ietf-uta-require-tls13.md
@@ -121,10 +121,11 @@ informative:
TLS 1.2 is in use and can be configured such that it provides good security
properties. TLS 1.3 use is increasing, and fixes some known deficiencies
-with TLS
-1.2, such as removing error-prone cryptographic primitives and encrypting
+with TLS 1.2.
+Examples of this include
+removing error-prone cryptographic primitives and encrypting
more of the traffic so that it is not readable by outsiders.
-For these reasons, new protocols must require and
+For these reasons, new protocols that use TLS must require and
assume the existence of TLS 1.3.
As DTLS 1.3 is not widely available or deployed,
this prescription does not pertain to DTLS (in any DTLS version); it pertains
to
@@ -144,14 +145,15 @@ deficiencies, as described in { {sec-considerations}}.
Note that addressing them usually requires bespoke configuration.
TLS 1.3 { {TLS13}} is also in
-widespread use and fixes most known deficiencies with TLS 1.2, such as
+widespread use and fixes most known deficiencies with TLS 1.2.
+Examples of this include
encrypting more of the traffic so that it is not readable by outsiders and
-removing most cryptographic primitives considered dangerous. Importantly, TLS
-1.3 enjoys robust security proofs and provides excellent security without
+removing most cryptographic primitives considered dangerous. Importantly, the
+protocol has had comprehensive security proofs and should provide excellent
security without
any additional configuration.
This document specifies that, since TLS 1.3 use is widespread, new protocols
-must require and assume its existence.
+that use TLS must require and assume its existence.
It updates { {RFC9325}} as described in { {rfc9325-updates}}.
As DTLS 1.3 is not widely available or deployed,
this prescription does not pertain to DTLS (in any DTLS version); it pertains
to
@@ -228,7 +230,7 @@ Again, these changes only apply to TLS, and not DTLS.
# Security Considerations {#sec-considerations}
TLS 1.2 was specified with several cryptographic primitives and design choices
-that have, over time, weakened its security. The purpose of this section is to
+that have, over time, become significantly weaker. The purpose of this section
is to
briefly survey several such prominent problems that have affected the protocol.
It should be noted, however, that TLS 1.2 can be configured securely; it is
merely much more difficult to configure it securely as opposed to using its
_______________________________________________
secdir mailing list -- sec...@ietf.org
To unsubscribe send an email to secdir-le...@ietf.org
wiki: https://wiki.ietf.org/group/secdir/SecDirReview
_______________________________________________
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
