Re: [Uta] Secdir last call review of draft-ietf-uta-rfc7525bis-07

[Thomas Fossati <[e-mail]>]

Ben: thanks a lot for the thorough review.

We are tracking your comments here: https://github.com/yaronf/I-D/issues?q=is%3Aopen+is%3Aissue+label%3A%22secdir+review%22 and will work to resolve them ASAP.

Cheers!

From: Benjamin Kaduk via Datatracker <[e-mail]>
Date: Thursday, 2 June 2022 at 04:16
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Secdir last call review of draft-ietf-uta-rfc7525bis-07
Reviewer: Benjamin Kaduk
Review result: Has Issues

I made a PR on github with some suggested fixes for essentially editorial
issues.  Some more substantive comments below.

There seem to be a handful of instances where we restate essentially the
same normative requirement (e.g., "SHOULD NOT use static FFDH keys") in
multiple places in the document.  I often recommend to just use the
normative keywords in one location and use normal prose to describe the
requirement when it is discussed elsewhere, to avoid the risk that the two
different phrasings of the normative requirement could be interpreted in
slightly different (conflicting) ways.

Section 3.1.1

   *  Implementations MUST NOT negotiate TLS version 1.0 [RFC2246].

      Rationale: TLS 1.0 (published in 1999) does not support many
      modern, strong cipher suites.  In addition, TLS 1.0 lacks a per-
      record Initialization Vector (IV) for CBC-based cipher suites and
      does not warn against common padding errors.  This and other
      recommendations in this section are in line with [RFC8996].

I'm not really sure why this is the best place to put the only mention of
RFC 8996 in relation to the requirements of this section.  8996 also
forbids both SSL versions and TLS 1.1, so why is TLS 1.0 special?
Perhaps it's better to move the 8996 reference into the list preface,
noting that we are building on top of its guidance and seek to impose
slightly more stringent/stronger requirements?

   *  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
      negotiate TLS version 1.2 over earlier versions of TLS.
      [...]
   *  Implementations SHOULD support TLS 1.3 [RFC8446] and, if
      implemented, MUST prefer to negotiate TLS 1.3 over earlier
      versions of TLS.

It's very disappointing to me to see that we label a TLS 1.3-only
implementation as non-compliant with the BCP for TLS usage; such an
implementation is more secure than a joint 1.2+1.3 implementation.
That said, I assume that the WG discussed this topic extensively and
it seems somewhat unlikely that I have any new contributions to that
discussion.

(Similarly for DTLS 1.3.)

   *  Implementations of newly-developed protocols SHOULD support TLS
      1.3 only with no negotiation of earlier versions, since there is
      no need to allow legacy endpoints that support TLS 1.2.

This seems like it is really more of guidance to protocol designers than
implementors thereof (yet we say "implementations of") -- if a new
protocol comes out that says "use TLS" (with no version requirements), an
implementation that limits itself to TLS 1.3 as this text recommends would
fail to interoperate with a different implementation of that protocol that
uses only TLS 1.2.

Section 3.2

                                               or via a method for
      dynamically upgrading a channel from unencrypted to TLS-protected
      (e.g., STARTTLS, which is used in protocols such as SMTP and
      XMPP).  [...]

FWIW, draft-ietf-nfsv4-rpc-tls has a "STARTTLS for NFSv4".

   *  HTTP client and server implementations MUST support the HTTP
      Strict Transport Security (HSTS) header [RFC6797], in order to
      allow Web servers to advertise that they are willing to accept
      TLS-only clients.

   *  Web servers SHOULD use HSTS to indicate that they are willing to
      accept TLS-only clients, unless they are deployed in such a way
      that using HSTS would in fact weaken overall security (e.g., it
      can be problematic to use HSTS with self-signed certificates, as
      described in Section 11.3 of [RFC6797]).

Looking at
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-08#section-9.5
calls to mind another scenario in which HSTS use is contraindicated: when
there are resources available only on the "http" origin that are not
accessible via "https" (or must be accessed via a different request path).
Only when we specialize from HTTP into "the Web" do we have a strong
expectation of equivalence of http and https resources (e.g., RFC 6265
cookies begin to erase the isolation between schemes).

I do note that the two bullet points I quote begin, respectively, with
"HTTP" and "Web", so in some sense this distinction is already being made.
But it is a quite subtle distinction, and I wonder if we might be able to
make some small tweaks (perhaps just adding another reference or two) to
provide a hint to the diligent reader.  I don't have any good suggestions
off the top of my head, but perhaps a friendly ART AD would be able to
oblige.

   *  Ticket keys MUST be changed regularly, e.g., once every week, so
      as not to negate the benefits of forward secrecy (see Section 7.3
      for details on forward secrecy).  Old ticket keys MUST be
      destroyed shortly after a new key version is made available.

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

The "half as long" recommendation seems to suggest a desire for seamless
key rotation (i.e., "force clients to get new tickets often enough that
they will get one with a newer key before their old one expires"), but the
"MUST be destroyed shortly after" requirement seems to preclude such an
operational scenario.  While resumption is just an optimization and it's
not like we're setting ourselves up for handshake failures, it does seem
like we might want to make our guidance paint a consistent picture on the
expected behavior around key-rotation events.
(N.B. that the above assumes that the "ticket keys" are the
"ticket-encryption keys" held solely by the server and used for
self-encrypting the stateless blob of session information, as I propose in
my PR.)

   *  TLS 1.2 does not roll the session key forward within a single
      session.  Thus, to prevent an attack where a stolen ticket key is
      used to decrypt the entire content of a session (negating the
      concept of forward secrecy), a TLS 1.2 server SHOULD NOT resume
      sessions that are too old, e.g. sessions that have been open
      longer than two ticket key rotation periods.  Note that this
      implies that some server implementations might need to abort
      sessions after a certain duration.

This is a slightly pedantic point, but the initial statement here is
"SHOULD NOT resume sessions", which relates to a separate scenario than
"might need to abort sessions".  The latter only comes into play if the
desire is to avoid using the single session key for too long a duration,
whereas not-resuming is a limitation only on the use of the ticket
associated with the session key, and makes no limitation on the actual use
of the session key for protecting application traffic.  Do we care more
about the resumption event or ongoing use of the corresponding session
key?

Separately, I have in my PR attempted to impose a distinction between the
"ticket-encryption key" (private to the server) and the "session key" (the
output of the handshake, shared by both client and server and used to
encrypt traffic).  I am not actually sure if the "stolen ticket key"
phrase is intended to refer to the "ticket-encryption key" or the "session
key" (or either), so some clarification would be appreciated.

   TLS 1.3 provides the powerful option of forward secrecy even within a
   long-lived connection that is periodically resumed.  Section 2.2 of
   [RFC8446] recommends that clients SHOULD send a "key_share" when
   initiating session resumption.  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.  [...]

It feels a little strange to me for this text to focus so heavily on
whether or not a "key_share" is present while making no mention of the
"psk_key_exchange_modes" extension that is used to actually negotiate the
PSK+ECDHE combination.  While on careful reading this text does appear to
be correct (it quotes what RFC 8446 says for clients to do and then offers
guidance on how servers should respond), I would suggest a minor tweak
like "...SHOULD select the "psk_dhe_ke" PSK key exchange mode and respond
with a "key_share", ..."

Section 3.5

   TLS 1.2 clients and servers MUST implement the renegotiation_info
   extension, as defined in [RFC5746].

Is this statement intended to also impose any requirement to implement the
TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value?  It might
be worth making an explicit statement about the SCSV, which is related to
but not exactly the same as the extension.

   TLS 1.2 clients MUST send renegotiation_info in the Client Hello.  [...]

Similarly, is this intended to allow for using the SCSV rather than the
empty extension?  If I remember correctly, OpenSSL always uses the SCSV
and never sends the empty extension in the ClientHello.

   A related attack resulting from TLS session parameters not properly
   authenticated is Triple Handshake [triple-handshake].  To address
   this attack, TLS 1.2 implementations SHOULD support the
   extended_master_secret extension defined in [RFC7627].

It surprised me that EMS is only a "SHOULD" given the scope of potential
issues if it is absent.  I tried to look for previous WG discussion on
this point, but found essentially nothing in the list archive for search
query "EMS" or "extended master secret".  Was there previous discussion
resulting in this being a "SHOULD" vs "MUST" or should we have such a
discussion now?

Section 3.8

   TLS implementations (both client- and server-side) MUST support the
   Application-Layer Protocol Negotiation (ALPN) extension [RFC7301].

   In order to prevent "cross-protocol" attacks resulting from failure
   to ensure that a message intended for use in one protocol cannot be
   mistaken for a message for use in another protocol, servers SHOULD
   strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]:
   "In the event that the server supports no protocols that the client
   advertises, then the server SHALL respond with a fatal
   no_application_protocol alert."  [...]

It feels a bit strange to have a "MUST support [RFC7301]" statement and
follow it up with only a "SHOULD strictly enforce [part of RFC 7301]".  If
you MUST do it, don't you need to always do it, not just sometimes (as
SHOULD would have it)?

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

I'd consider following this with a clause "but strict enforcement of ALPN
usage may not be feasible when the ALPN identifier is registered for a
well-established protocol".

Section 4.1

      Rationale: Based on [RFC3766], at least 112 bits of security is
      needed.  40-bit and 56-bit security are considered insecure today.
      TLS 1.2 never negotiates 40-bit or 56-bit export ciphers and such
      ciphers are not supported at all in TLS 1.3.

I don't think I understand the basis for the last sentence here -- while
a TLS 1.2 implementation conformant to this BCP will never negotiate
export ciphers, I don't see that it's intrinsically a property of TLS 1.2
to not do so.  For example, OpenSSL 1.0.2 seems to be willing to negotiate
such ciphers for TLS 1.2.

Section 4.2

   When using ECDSA signatures for authentication of TLS peers, it is
   RECOMMENDED that implementations use the NIST curve P-256.  In
   addition, to avoid predictable or repeated nonces (that would allow
   revealing the long term signing key), it is RECOMMENDED that
   implementations implement "deterministic ECDSA" as specified in
   [RFC6979] and in line with the recommendations in [RFC8446].

Did we consider adding a note that when hardware-fault or similar attacks
are a concern, randomness and deterministic signing might be combined, as
investigated in draft-mattsson-cfrg-det-sigs-with-noise?  There is some
text to this effect in
https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-12#section-2.1.1
that might be used as a starting point.

Section 4.5

   As noted in [RFC3766], correcting for the emergence of a TWIRL
   machine would imply that 1024-bit DH keys yield about 65 bits of
   equivalent strength and that a 2048-bit DH key would yield about 92
   bits of equivalent strength.  [...]

I didn't find the specific values for these bit strengths precomputed in
3766 in a quick search; I assume that there is some formula being used but
we have to plug in our own numbers to get the values listed here.  I did
see https://datatracker.ietf.org/doc/html/rfc3766#section-5.1 say
essentially "subtract 11 bits of strength" but that doesn't help me line
these numbers up to other ones I'm used to seeing.

Section 7.2

   Section 4.2 above recommends the use of the AES-GCM authenticated
   encryption algorithm.  Please refer to Section 11 of [RFC5246] for
   general security considerations when using TLS 1.2, [...]

The referenced section itself just says "security issues are discussed
throughout this memo" and mentions a few appendices.  Perhaps the section
reference is not adding much for us and we should just reference 5246 in
its entirety?

Section 7.5

                                             For an up-to-date survey of
      the status of OCSP deployment in the Web PKI see [Chung18].

Is a reference from 2018 still "up-to-date" in 2022?

   the status_request extension differs between TLS 1.2 and 1.3.  As a
   matter of local policy, server operators MAY request that CAs issue
   must-staple [RFC7633] certificates for the server and/or for client
   authentication, but we recommend to review the operational conditions
   before deciding on this approach.

Do we believe that the operational considerations in question are
sufficiently described by RFC 7633 or might there be an additional
resource to reference here?

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.