Hi,
I reviwed the whole document. Looks fine in general. Some comments:
- "Those who implement and deploy TLS and DTLS, in particular versions 1.2 or
earlier of these protocols"
Delete "or earlier". As these versions are "MUST NOT negotiate". Might be good
to mention this deprecation in the introduction.
- Would be good for the reader if the intro said something to explain the TLS
handshake and record layer. DTLS and QUIC also use the TLS handshake but with a
different record layer. Would be good to point out that a lot of the
recommendations for "TLS" apply to all uses of the TLS handshake such as DTLS
and QUIC.
- I think QUIC should be mentioned in the introduction. Otherwise the document
feels old already when it is published. QUIC already makes up a huge part of
internet traffic. Over 25% in some ISP. Many of the recommendations apply to
QUIC as well
- 3.3. Compression
Would be good to add that TLS certificate compression is fine to use.
- of time (e.g., measured in days)
"Days" is ridiculasly long for non-constrained use cases. ANSSI requires
ephemeral diffie-hellman every hour or 100 GB for IPsec. Signal and WireGuard
are doing Diffie-Hellman much more often than that. I think "measured in days"
give the wrong idea. I suggest changing to "e.g., every hour". Days seems like
a recommendation taken from the year 2000. If needed separate contrained and
non-constrained use cases.
- "Renegotiation in TLS 1.2 was replaced"
Change to "partly replaced". Diffie-Hellman, server authentication, and update
of the exporter secret are all missing.
- Section 4.1
I am missing a recommendation related to AEAD. I would make sense to add that
"Implementations SHOULD NOT negotiate non-AEAD cipher suites."
- "Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the first
proposal to any server, unless they have prior knowledge that the server cannot
respond to a TLS 1.2 client_hello message."
I would delere ", unless ...". This does not align with MUST NOT negotiate 1.1
- "When using RSA, servers SHOULD authenticate using certificates with at
least a 2048-bit modulus for the public key."
This needs to be "MUST" to alging with "MUST NOT negotiate cipher suites
offering less than 112 bits of security"
- The document should talk about the need to start phasing out RSA-2048 and
2048-bit DH keys which both gives 112-bit security. BSI requires that RSA-2048
disabled by January 2023. CA Browser forum has already forbidden RSA-2048 for
use with code signing.
- 7.1. The document should make it clear without Host Name Validation there is
typically no authentication. The TLS handshake only provides
proof-of-possestion of the private key and transfers certificates so that the
application can do authentication.
Cheers,
John
From: Uta <uta-boun...@ietf.org> on behalf of internet-dra...@ietf.org
<internet-dra...@ietf.org>
Date: Thursday, 26 May 2022 at 23:22
To: i-d-annou...@ietf.org <i-d-annou...@ietf.org>
Cc: uta@ietf.org <uta@ietf.org>
Subject: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.
Title : Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS)
Authors : Yaron Sheffer
Peter Saint-Andre
Thomas Fossati
Filename : draft-ietf-uta-rfc7525bis-07.txt
Pages : 39
Date : 2022-05-26
Abstract:
Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) are widely used to protect data exchanged over application
protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the
years, the industry has witnessed several serious attacks on TLS and
DTLS, including attacks on the most commonly used cipher suites and
their modes of operation. This document provides the latest
recommendations for ensuring the security of deployed services that
use TLS and DTLS. These recommendations are applicable to the
majority of use cases.
An earlier version of this document was published as RFC 7525 when
the industry was in the midst of its transition to TLS 1.2. Years
later this transition is largely complete and TLS 1.3 is widely
available. This document updates the guidance given the new
environment and obsoletes RFC 7525. In addition, the document
updates RFC 5288 and RFC 6066 in view of recent attacks.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-uta-rfc7525bis-07.html
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc7525bis-07
Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
