[Uta] AD Review of draft-ietf-uta-rfc7525bis-06

[Francesca Palombini <[e-mail]>]

Thank you for the work on this document, well written and easy to read. I don't have major comments. I have some minor comments, and a couple of nits or request for clarifications, which you can address together with any other Last Call comments.

Many thanks to Paul Wouters who has provided an early SEC AD review - I think his mail might have been blocked in moderation queue because I can't find it in the mailarchive, so I will copy it at the end of my mail here. Authors: as I don’t see major blocking comments from Paul, I will not delay Last Call, but will look forward to your answers to Paul’s very valid comments as well.

Francesca

1. -----

FP: DTLS 1.3 has been published, please update the reference to RFC9147

2. -----

   This document attempts to minimize new guidance to TLS 1.2
   implementations, and the overall approach is to encourage systems to
   move to TLS 1.3.  However this is not always practical.  Newly

FP: I believe this is the first time TLS 1.3 appear (excluding the abstract) so it would be good to add a reference to RFC 8446 here. On the same note, there are a number of protocols named as examples, but with no references, it would be good to add some informative references for these (SMTP, IMAP, POP3, SIP, XMPP, IRC, SRTP)

3. -----

FP: Has the working group had a discussion about the "Updates" header tag for this document? The two existing ones are quite straightforward, but I wondered if it would make sense to add the TLS and DTLS docs there as well, to provide an easy link for implementers to more easily find this BCP.

4. -----

   more secure PSK-based mechanism is described in Section 4.6.1 of
   [RFC8446].  See this post (https://blog.filippo.io/we-need-to-talk-
   about-session-tickets/) by Filippo Valsorda for a comparison of TLS
   1.2 and 1.3 session resumption, and [Springall16] for a quantitative
   study of TLS cryptographic "shortcuts", including session resumption.

FP: Can we add the blog post as reference, and take a stable screenshot of it to include as reference in this document?

5. -----


   *  For similar reasons, session ticket validity SHOULD be limited to
      a reasonable duration (e.g., half as long as ticket key validity).

FP: It would be good to expand on why this is not a MUST, i.e. what is the expected exception case. Also I appreciate the example, but it is hard to define what a "reasonable duration" is, maybe something more can be added here?

6. -----

   of protocols that multiplex requests over a single connection (such
   as HTTP/2), post-handshake authentication has the same problems as

FP: Please add a reference to HTTP/2 (draft-ietf-httpbis-http2bis-07).

7. -----

   mistaken for a message for use in another protocol, servers should
   strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]:

FP: I am wondering why this "should" and not "need to" or "ought to", or even MUST.

8. -----

FP: Running the ID Nits I also get the following warning:

     (Using the creation date from RFC5288, updated by this document, for
     RFC5378 checks: 2007-06-19)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

Were the original authors of RFC 5288 involved?


=====================

From: Paul Wouters
Date: Monday, 16 May 2022 at 04:03
To: [e-mail]
Cc: Francesca Palombini
Subject: Review of draft-ietf-uta-rfc7525bis-06


This is a good document. I do have a view specific comments. One larger overview
question I have is if the authors have thought about using tables to summarize
changes, instead of the Appendix A style write up of changes?

Specific comments and nits follow below,

Paul



-     We note that
       as long as TLS 1.2 is still allowed by a particular
       implementation, even if it defaults to TLS 1.3, implementers MUST
       still follow all the recommendations in this document.

What is this really trying to say? "MUST is a MUST" is not something we need to clarify

-  Similarly, we RECOMMEND that new protocol designs that embed the TLS mechanisms
       (such as QUIC has done [RFC9001]) include TLS 1.3

I would not say "include" but really say "be based on" as no one new
should make something based on TLS 1.2.

-     In cases where an application protocol allows implementations or
       deployments a choice between strict TLS configuration and dynamic
       upgrade from unencrypted to TLS-protected traffic (such as
       STARTTLS), clients and servers SHOULD prefer strict TLS
       configuration.

First of all, why is this a SHOULD and not a MUST? Especially since "prefer" seems to also
weaken this already. And second, does prefer mean a fallback to dynamic upgrade is allowed
if a strict configuration fails? If so, does that apply to all kind of failures? Is this
not introducing a downgrade attack?

- A client SHOULD attempt to negotiate TLS even if these
       indications are not communicated by the server.

Again, why a SHOULD and not a MUST ? I guess this is why the above uses "prefer" or else there
would be a contradiction.

- [compression] unless the application protocol in question has been shown not to be open to such attacks.

Can something perhaps be said about the standard HTTPS "application" ? eg browsers ? Is
it safe or not to support there?

-  In order to gain forward secrecy,
    this document recommends that server implementations SHOULD respond
    with a "key_share", to complete an ECDHE exchange on each session
    resumption.

Doesn't this mostly negate the "essential performance feature" of TLS session resumption?

    Protocol developers are strongly encouraged to register an ALPN
    identifier for their protocols.  This applies to new protocols, as
    well as well-established protocols such as SMTP.

This seems like a directive in an RFC to the IETF - get an ALPN for SMTP. We should just start
that process instead of passive aggressively writing that in an RFC :)

    When using ECDSA signatures for authentication of TLS peers, it is
    RECOMMENDED that implementations use the NIST curve P-256.

Why only P-256? Why not P-384 or P-521 ?

    The Logjam attack [Logjam] further
    demonstrates that 1024-bit Diffie Hellman parameters should be
    avoided.

Why is this should a lowercase? Also why not simply a "MUST NOT use" ?


Comments:

- The abstract is copied from its 7 years old predecessor, which feels a little dated when it again
   claims "Over the years [...]. Perhaps a better way is a more generic txt. For example see RFC 8247.

- "This document provides recommendations for
    improving the security of deployed services that use TLS and DTLS."

   That sounds a bit arrogant. Good deployments might have nothing to improve.
   Just state this document provides the latest recommendations.

- "This document is being republished"
   This feels odd, the IETF does not "republish". Perhaps "This document has been updated with this in mind"

- In fact, the cipher suites
   recommended by this document for TLS 1.2 (Section 4.2 below) are
   only available in this version.

Why are they not in TLS 1.3 ? :P Or are they?

- Implementations of "greenfield" protocols or deployments, where
   there is no need to support legacy endpoints

I don't think "protocols" applies here. It really just says "if you are
a greenfield deployment (you manage all the nodes communicatiing), you could
insist on TLS 1.3 only.

- See this post (https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-f50c199c2e19ebfa&q=1&e=a0863fc0-c9b6-43b3-b9a6-18db1298e613&u=https%3A%2F%2Fblog.filippo.io%2Fwe-need-to-talk-
    about-session-tickets/)

Turn into a proper informative reference ? Also, it is a weak link and likely to break
over the next few years.

- Section 3.5 seems to miss an introduction line of what renegotiation is, similar to
how 3.4 states what session resumption is (sort of)

- (formerly called Encrypted SNI)

I think this reference can be removed, it was really only a draft name and not something with
actual deployment that people "know". Also "formerly called" is misleading, it was something
completely different that had the same goal as ECH.

    TLS and its implementations provide considerable flexibility in the
    selection of cipher suites.

I wouldn't say that for TLS 1.3 ? It does still apply to TLS 1.2.

    algorithms that were once considered strong become weak.  Such
    algorithms need to be phased out over time

I think "such" here is misleading. It feels like referencing "weak
algorithms" yet we are talking about replacing algorithms before
these become week. I would simply remove the word "Such".

       TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers.

This (misleadingly) suggests TLS 1.3 might however do this?

       Implementations SHOULD NOT negotiate cipher suites that use
       algorithms offering less than 128 bits of security.

       Rationale: Cipher suites that offer between 112-bits and 128-bits
       of security are not considered weak at this time

These sentences together lead to a weird case for 128. Even though it looks
a little weird, I would say either "between 112-bits and 127-bits" or "more
than 112-bits but less than 128-bits".

Also, how long have we had 128 bit ciphers? Can we really not say MUST NOT
instead of SHOULD NOT for the 112-127 range? Also in light of Grover's algorithm
that brings 256 back to effectively 128?

       Rationale: Forward secrecy (sometimes called "perfect forward
       secrecy") prevents the recovery of information that was encrypted
       with older session keys, thus limiting the amount of time during
       which attacks can be successful.  See Section 7.3 for a detailed
       discussion.

I think this should be rewritten a little? It's not that attack time
is limited, but really the exposure after a successful attack. Eg if
the vulnerability is not fixed, PFS won't help you as for each session
the attacker is either still there or regains access using the same
vulnerability. I would more clearly say "limits how far back in time
data can be decrypted when an attack is successfull".




Nits:
    "An earlier version of this document was published as RFC 7525"

more common is to write:

    "This document obsoletes RFC 7525"

     Version 1.3 of TLS [RFC8446] was released and version 1.3 of DTLS
       was finalized [I-D.ietf-tls-dtls13]

This reference can be updated now but requires textual change ("finalized" no longer needed)

    "leak will be plugged by use of" -> leak is closed by using

    "It is also RECOMMENDED that clients abort" -> Clients SHOULD abort

SEction 3.7, 3.8 I would also add the acronym in the section title.

    "It is also RECOMMENDED that clients" -> Clients SHOULD

improved latency -> reduced latency

because they are  -> because these are

but they are out of scope -> but these are out of scope

"[RFC8422]" appears without proper linking in 4.2.1

  [I-D.ietf-tls-dtls13] can be updated to [RFC9147]

    Clients MUST indicate to servers that they request SHA-256, by using
    the "Signature Algorithms" extension defined in TLS 1.2.

Maybe start with: "TLS 1.2 client MUST ....."

  current state of the art -> best current practises ?