Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt

[Thomas Fossati <[e-mail]>]

Hi John, thank you very much for your review.

We are tracking your comments here:


  *   https://github.com/yaronf/I-D/issues/377
  *   https://github.com/yaronf/I-D/issues/378
  *   https://github.com/yaronf/I-D/issues/379
  *   https://github.com/yaronf/I-D/issues/380
  *   https://github.com/yaronf/I-D/issues/381
  *   https://github.com/yaronf/I-D/issues/382
  *   https://github.com/yaronf/I-D/issues/383
  *   https://github.com/yaronf/I-D/issues/384

With regards to:

-  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.

This was already fixed in the editor’s copy (by Ben):


  *   https://github.com/yaronf/I-D/pull/358/commits/c39180c

cheers, thanks!

From: Uta <[e-mail]> on behalf of John Mattsson <john.mattsson=[e-mail]>
Date: Friday, 10 June 2022 at 14:25
To: [e-mail] <[e-mail]>
Subject: Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
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 <[e-mail]> on behalf of [e-mail] <[e-mail]>
Date: Thursday, 26 May 2022 at 23:22
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/uta
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.