I have proposed a bunch of edits to the draft, in
https://github.com/richsalz/draft-use-tls13/pull/2
The summary is the following:
* Remove the "or later" part of "TLS 1.3 or later"
* Move to standards-track so it can update BCP 195 and RFC 9325
* Mention LAMPS and TLS, not UTA as WG's doing work on PQC
* Various wording fixes.
* Add paragraph on what applications should do: if the library they are
using supports it, specify the minimum TLS version as appropriate.
The full diff is attached.
FYI I’ll be on vacation 24 Apr to 1 May (inclusive).
diff --git a/draft-ietf-uta-require-tls13.md b/draft-ietf-uta-require-tls13.md
index e8d7363..a19f920 100644
--- a/draft-ietf-uta-require-tls13.md
+++ b/draft-ietf-uta-require-tls13.md
@@ -1,7 +1,8 @@
---
title: "New Protocols Must Require TLS 1.3"
abbrev: "require-tls1.3"
-category: info
+category: std
+updates: 9325
docname: draft-ietf-uta-require-tls13-latest
submissiontype: IETF
@@ -49,9 +50,12 @@ informative:
PQUIPWG:
target: https://datatracker.ietf.org/wg/pquip/about/
title: Post-Quantum Use in Protocols
- uta:
- target: https://datatracker.ietf.org/wg/uta/about/
- title: Using TLS in Applications
+ LAMPSWG:
+ target: https://datatracker.ietf.org/wg/lamps/about/
+ title: Limited Additional Mechanisms for PXIK and SMIME
+ TLSWG:
+ target: https://datatracker.ietf.org/wg/tls/about/
+ title: Transport Layer Security
TRIPLESHAKE:
target: https://mitls.org/pages/attacks/3SHAKE
title: Triple Handshakes Considered Harmful Breaking and Fixing
Authentication over TLS
@@ -161,8 +165,9 @@ experience shows that configuration mistakes are common,
especially when
deploying cryptography.
See {{sec-considerations}} for elaboration.
-3. The original protocol, as-is, does not provide security {{RENEG1}},
-{{RENEG2}}, {{TRIPLESHAKE}}. Rather, some extensions are required to provide
+3. The base protocol does not provide security against some
+types of attacks (see {{sec-considerations}});
+extensions are required to provide
security.
In contrast, TLS 1.3 {{TLS13}} is also in
@@ -184,30 +189,30 @@ TLS only.
Cryptographically-relevant
quantum computers (CRQC), once available, will have a huge impact on TLS.
-In 2016, the US National Institute of Standards and Technology started a
+In 2016, the US National Institute of Standards and Technology (NIST) started a
multi-year effort to standardize algorithms that will be "safe"
once quantum computers are feasible {{PQC}}. First IETF discussions happened
around the same time {{CFRGSLIDES}}.
While the industry is waiting for NIST to finish standardization, the
IETF has several efforts underway.
-A working group was formed in early 2013 to work on use of PQC in IETF
protocols,
+A working group was formed in early 2023 to work on use operational and
+transitional uses of PQC in IETF protocols,
{{PQUIPWG}}.
-Several other working groups, including TLS {{uta}},
+Several other working groups, notably LAMPS {{LAMPSWG}} and TLS {{TLSWG}},
are working on
drafts to support hybrid algorithms and identifiers, for use during a
transition from classic to a post-quantum world.
For TLS it is important to note that the focus of these efforts is TLS 1.3
-or later.
+or later:
TLS 1.2 WILL NOT be supported (see {{iana}}).
This is one more reason for new protocols to default to TLS 1.3, where
post-quantum cryptography is expected to be supported.
-# TLS Use by Other Protocols
+# TLS Use by Other Protocols and Applications
-Any new protocol that uses TLS MUST specify as its default TLS 1.3 (or a higher
-TLS version, when one becomes stadardized).
+Any new protocol that uses TLS MUST specify as its default TLS 1.3.
For example, QUIC {{QUICTLS}} requires TLS 1.3 and specifies that endpoints
MUST terminate the connection if an older version is used.
@@ -218,10 +223,21 @@ TLS 1.2 as the default, while also allowing TLS 1.3.
For newer specifications that choose to support TLS 1.2, those preferences are
to be reversed.
+The initial TLS handshake allows a client to specify which versions of
+the TLS protocol it supports and the server is intended to pick the highest
+version that it also supports.
+This is known as the "TLS version negotiation," and
+many TLS libraries provide a way for applications to specify the range
+of versions.
+When the API allows it, clients SHOULD specify just the minimum version they
+want.
+This SHOULD be TLS 1.3 or TLS 1.2, depending on the circumstances described
+in the above paragraphs.
+
# Security Considerations {#sec-considerations}
TLS 1.2 was specified with several cryptographic primitives and design choices
-that have historically hindered its security. The purpose of this section is to
+that have, over time, its security. 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
@@ -229,23 +245,23 @@ modern successor, TLS 1.3. See {{!RFC9325}} for a more
thorough guide on the
secure deployment of TLS 1.2.
Firstly, the TLS 1.2 protocol, without any extension points, is vulnerable to
-the renegotiation attack and the Triple Handshake attack. Broadly, these
attacks
+renegotiation attacks (see {{RENEG1}} and {{RENEG2}} and the
+Triple Handshake attack (see {{TRIPLESHAKE}}.
+Broadly, these attacks
exploit the protocol's support for renegotiation in order to inject a prefix
chosen by the attacker into the plaintext stream. This is usually a devastating
threat in practice, that allows e.g. obtaining secret cookies in a web setting.
-Refer to {{RENEG1}}, {{RENEG2}}, {{TRIPLESHAKE}} for elaboration. In light of
+In light of
the above problems, {{!RFC5746}} specifies an extension that prevents this
category of attacks. To securely deploy TLS 1.2, either renegotiation must be
-disabled entirely, or this extension must be present. Additionally, clients
must
+disabled entirely, or this extension must be used. Additionally, clients must
not allow servers to renegotiate the certificate during a connection.
Secondly, the original key exchange methods specified for the protocol, namely
RSA key exchange and finite field Diffie-Hellman, suffer from several
-weaknesses. As before, to securely deploy the protocol, these key exchange
+weaknesses. Similarly, to securely deploy the protocol, these key exchange
methods must be disabled.
-Refer to draft-obsolete-kex for elaboration (TODO I guess we will anyway
-wait for WGLC for draft-obsolete-kex, so no sense to temporarily refer to the
-draft.)
+See {{!I-D.draft-ietf-tls-deprecate-obsolete-kex}} for details.
Thirdly, symmetric ciphers which were widely-used in the protocol, namely RC4
and CBC cipher suites, suffer from several weaknesses. RC4 suffers from
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
