Re: [TLS] AD review of draft-ietf-tls-tls13-cert-with-extern-psk-02

[Russ Housley <[e-mail]>]

Ben:

I have made the edits indicated in my response below.  I cannot pot it until the I-D repository reopens.

> Thanks for putting this together, and sorry again for the delays in
> processing.
> 
> I note inline many places where we essentially repeat preexisting
> requirements from RFC 8446 but use normative keywords as if they were
> new requirements being imposed by this document.  (There are other places
> where we repeat or duplicate some narrative descriptions from RFC 8446 as
> well, though I did not note specific locations.) I think our general
> preference is to try to only use the normative keywords once, and have
> either direct quotations or descriptive language for other places where we
> refer to those requirements, though of course there are always exceptions.
> 
> Similarly, we may have more duplication of content/requirements between
> Sections 4 and 5 than is needed.
> 
> Some other section-by-section notes are included as well, in particular for
> the IANA Considerations that will need some tweaking.
> 
> Section 3
> 
>   The invention of a large-scale quantum computer would pose a serious
>   challenge for the cryptographic algorithms that are widely deployed
>   today, including the digital signature algorithms that are used to
>   authenticate the server in the TLS 1.3 handshake protocol.  It is an
>   open question whether or not it is feasible to build a large-scale
>   quantum computer, and if so, when that might happen.  However, if
>   such a quantum computer is invented, many of the cryptographic
>   algorithms and the security protocols that use them would become
>   vulnerable.
> 
> Apparently we don't have an RFC style entry for "the kind of quantum
> computer that we have to worry about for cryptographic purposes"; I see
> reference to "sufficiently large quantum computer" (RFC 8080),
> "large-scale quantum computer" (RFC 8576), "cryptographically relevant
> quantum computer" (RFC 8603), and there's probably more that didn't jump
> out at me.  (This question did just come up in response to my review of
> draft-ietf-ipsecme-qr-ikev2, where Scott Fluhrer suggested
> "cryptographically significant quantum computer", that I was going to
> lean towards until I did this search just now.)  It would be great to
> normalize our terminology use here, though I don't know that there's a
> clear winner yet.
> (I also wonder if "invention" is quite the right word to describe the
> process in question, but that's probably a side note.)

One of your references is using "large-scale quantum computer" as I do in this document.  I can see that alignment on a single term would be desirable, but I do not think that a common term has emerged in the greater research community.

I will gladly change "invention" to "development" in the first sentence.

>   The TLS 1.3 handshake protocol employs key agreement algorithms that
>   could be broken by the invention of a large-scale quantum computer
>   [I-D.hoffman-c2pq].  These algorithms include Diffie-Hellman (DH)
>   [DH1977] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363].  As a
> 
> It might be worth using "also employs" to emphasize that the signature
> algorithms of the first paragraph and the key-agreement algorithms of
> the second paragraph are distinct classes of algorithms.
> Also, do we want to also reference RFC 7748 to get an "I*TF-internal"
> reference for ECDH technologies?

I am using the same reference for ECDH as RFC 8446.  This was intensional.

I suggest the following to bring in the signature algorithm concern:

   The TLS 1.3 handshake protocol employs key agreement algorithms and
   digital signature algorithms that could be broken by the development
   of a large-scale quantum computer [I-D.hoffman-c2pq].  The key
   agreement algorithms include Diffie-Hellman (DH) [DH1977] and
   Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital
   signature algorithms inclue RSA [RFC8017] and Elliptic Curve Digital
   Signature Algorithm (ECDSA) [FIPS186].  As a result, an adversary
   that stores a TLS 1.3 handshake protocol exchange today could decrypt
   the associated encrypted communications in the future when a large-
   scale quantum computer becomes available.

> Section 4
> 
>   The client includes the "tls_cert_with_extern_psk" extension in the
>   ClientHello message.  The "tls_cert_with_extern_psk" extension MUST
>   be accompanied by the "key_share", "psk_key_exchange_modes", and
> 
> Do we need to mandate anything about the contents of
> "psk_key_exchange_modes" in this case?  (I see we do say something later
> on in Section 5, so maybe not here.  But see also the note about
> duplication of normative requirements between Sections 4 and 5.)

I think the discussion in Section 5 covers this extension well.  RFC 8446 defines two values (psk_ke and psk_dhe_ke), and both are discussed in Section 5.

>   "pre_shared_key" extensions.  The "pre_shared_key" extension MUST be
>   the last extension in the ClientHello message, and it provides a list
>   of external PSK identifiers that the client is willing to use with
>   this server.  [...]
> 
> I think that the last paragraph of
> https://tools.ietf.org/html/rfc8446#section-4.2.11 is quite clear that
> "pre_shared_key" must be the last extension, and we don't need to have
> new normative language to require it.

Okay.  I'd like to preserve the reminder that the "pre_shared_key" extension needs to come at the end.  I suggest:

   The client includes the "tls_cert_with_extern_psk" extension in the
   ClientHello message.  The "tls_cert_with_extern_psk" extension MUST
   be accompanied by the "key_share", "psk_key_exchange_modes", and
   "pre_shared_key" extensions.  The client MAY also find it useful to
   include the "supported_groups" extension.  Since the
   "tls_cert_with_extern_psk" extension is intended to be used only with
   initial handshakes, it MUST NOT be sent alongside the "early_data"
   extension.  These extensions are all described in Section 4.2 of
   [RFC8446], which also requires the "pre_shared_key" extension to be
   the last extension in the ClientHello message.

>   The successful negotiation of the "tls_cert_with_extern_psk"
>   extension requires the TLS 1.3 key schedule processing to include
>   both the selected external PSK and the (EC)DHE shared secret value.
> 
> grammar pedant alert: I believe that this construction is parsed such
> that inclusion of (both external PSK and ECDHE shared secret) in the key
> schedule is a prerequisite for successful negotiation, whereas the
> intent is that successful negotiation implies the key schedule change.
> One plausible "fix" (if any is indeed desired) would be "After
> successful negotiation [...], it is required to adopt the TLS 1.3 key
> schedule [...]", but there are probably better ones.

I think this is an improvement:

   When the "tls_cert_with_extern_psk" extension is successfully
   negotiated, the TLS 1.3 key schedule processing includes both the
   selected external PSK and the (EC)DHE shared secret value.  As a
   result, the Early Secret, Handshake Secret, and Master Secret values
   all depend upon the value of the selected external PSK.

>   As a result, the Early Secret, Handshake Secret, and Master Secret
>   values all depend upon the value of the selected external PSK.
> 
> (side note) Not that anyone here is likely to be confused, but the Early
> Secret does not incorporate the (EC)DHE shared secret.  I don't really
> see any reason to include a clarification about this, since the current
> text isn't really implying that it does, but will mention it in case
> anyone feels differently.

To make sure this is clear, I suggest and additional sentence to the above:

    Of course, the Early Secret does not depend upon
    the (EC)DHE shared secret.

>   Each external PSK is associated with a single hash algorithm, which
>   is required by Section 4.2.11 of [RFC8446].  The hash algorithm MUST
>   be set when the PSK is established, with a default of SHA-256 if no
>   hash algorithm is specified during establishment.
> 
> This is likely to get flagged by the IESG -- it's a construction of the
> form "MUST do X, but if you don't do X, assume Y" that inherently
> assumes the MUST will not always be adhered to.

I think this says the same thing with a cleaner construction:

   Each external PSK is associated with a single hash algorithm, which
   is required by Section 4.2.11 of [RFC8446].  The hash algorithm MUST
   be set when the PSK is established, with a default of SHA-256.

> Section 5
> 
> Is there a useful way to group this content into sub-sections?

Yes. I have introduces subsections to talk about the companion extensions, authentication, and keying material.

>   appeared in the preceding ClientHello message.  If an implementation
>   recognizes the "tls_cert_with_extern_psk" extension and receives it
>   in any other message, then the implementation MUST abort the
>   handshake with an "illegal_parameter" alert.
> 
> nit: "abort the handshake" is not quite right, since there are
> Extensions blocks involved in post-handshake messages (NST,
> CertificateRequest, etc.) which do not have a handshake to abort.  I
> think "terminate the connection with a <foo> alert" is the preferred
> construction for this situation.

Since the "tls_cert_with_extern_psk" extension MUST NOT appear in any message other than the ClientHello message and the ServerHello message, I think this is the correct construction.  For example, Section 4.1.1 of RFC 8446 says:

   ...  If there is no overlap between the received
   "supported_groups" and the groups supported by the server, then the
   server MUST abort the handshake with a "handshake_failure" or an
   "insufficient_security" alert.

>   ClientHello message.  If the server responds with a HelloRetryRequest
>   message, then the client sends another ClientHello message as
>   described in Section 4.1.2 of [RFC8446], and it MUST include the same
>   "tls_cert_with_extern_psk" extension as the original ClientHello
>   message or abort the handshake.
> 
> (This is another MUST that duplicates an existing requirement from RFC
> 8446.)

Okay.  Reworded to remove the MUST:

   ...  If the server responds with a HelloRetryRequest
   message, then the client sends another ClientHello message as
   described in Section 4.1.2 of [RFC8446], including the same
   "tls_cert_with_extern_psk" extension as the original ClientHello
   message or abort the handshake.

>   Many server extensions are carried in the EncryptedExtensions
>   message; however, the "tls_cert_with_extern_psk" extension is carried
>   in the ServerHello message.  It is only present in the ServerHello
> 
> I suggest adding a brief phrase noting that it's unfeasible to put this
> extension in the EncryptedExtensions since it affects what key is used
> to encrypt that message.

I suggest:

   Many server extensions are carried in the EncryptedExtensions
   message; however, the "tls_cert_with_extern_psk" extension is carried
   in the ServerHello message.  Successful negotiation of the
   "tls_cert_with_extern_psk" extension affects the key used for
   encryption, so it cannot be carried in the EncryptedExtensions
   message.  Therefore, the "tls_cert_with_extern_psk" extension is only
   present in the ServerHello message if the server recognizes the
   "tls_cert_with_extern_psk" extension and the server possesses one of
   the external PSKs offered by the client in the "pre_shared_key"
   extension in the ClientHello message.

>   To use an external PSK with certificates, clients MUST provide the
>   "tls_cert_with_extern_psk" extension, and it MUST be accompanied by
>   the "key_share", "psk_key_exchange_modes", and "pre_shared_key"
>   extensions in the ClientHello.  If clients offer a
>   "tls_cert_with_extern_psk" extension without all of these other
>   extensions, servers MUST abort the handshake.  The client MAY also
> 
> This seems redundant with the requirements from Section 4; is the
> repetition necessary?

I moved the one sentence that was not a repeat to Section 4 (as shown above).  With that done, the whole paragraph can be deleted.

>   find it useful to include the "supported_groups" extension.  Note
>   that Section 4.2 of [RFC8446] allows extensions to appear in any
>   order, with the exception of the "pre_shared_key" extension, which
>   MUST be the last extension in the ClientHello.  Also, there MUST NOT
>   be more than one instance of each extension in the ClientHello
>   message.
> 
> I'd prefer to either use direct quotations from RFC 8446 or descriptive
> versions of the requirements (without normative keywords).

Okay.  This one was deleted.

>   might supply via a subsequent NewSessionTicket.  As a result, clients
>   MUST include the psk_dhe_ke mode, and clients MAY also include the
>   psk_ke mode to support a subsequent NewSessionTicket.  Servers MUST
>   select the psk_dhe_ke mode for the initial handshake.  Servers MUST
>   select a key exchange mode that is listed by the client for
>   subsequent handshakes that include the resumption PSK from the
>   initial handshake.
> 
> I suppose it's probably implicit that "MUST select the psk_dhe_ke mode"
> is contingent on negotiating "tls_cert_with_extern_psk", but maybe
> there's not any harm in making it explicit as well.

I suggest:

   The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of
   [RFC8446].  The "psk_key_exchange_modes" extension restricts both the
   use of PSKs offered in this ClientHello and those which the server
   might supply via a subsequent NewSessionTicket.  As a result, when
   the "psk_key_exchange_modes" extension is included in the ClientHello
   message, clients MUST include psk_dhe_ke mode.  In addition, clients
   MAY also include psk_ke mode to support a subsequent
   NewSessionTicket.  When the "psk_key_exchange_modes" extension is
   included in the ServerHello message, servers MUST select the
   psk_dhe_ke mode for the initial handshake.  Servers MUST select a key
   exchange mode that is listed by the client for subsequent handshakes
   that include the resumption PSK from the initial handshake.

>   The "pre_shared_key" extension is defined in Section 4.2.11 of
>   [RFC8446].  The syntax is repeated below for convenience.  All of the
>   listed PSKs MUST be external PSKs.
> 
> Should we specify that the server must abort the handshake if it detects
> a resumption PSK present in a ClientHello that contains
> "tls_cert_with_extern_psk"?  (What alert would be best in that case?)

I suggest:

   The "pre_shared_key" extension is defined in Section 4.2.11 of
   [RFC8446].  The syntax is repeated below for convenience.  All of the
   listed PSKs MUST be external PSKs.  If a resumption PSK is listed
   along with the "tls_cert_with_extern_psk" extension, the server MUST
   abort the handshake with an "illegal_parameter" alert.

>   The obfuscated_ticket_age is not used for external PSKs; clients
>   SHOULD set this value to 0, and servers MUST ignore the value.
> 
> (These are the same requirements from RFC 8446, though it's probably
> reasonable to repeat them here to confirm that they apply.)

To be clear that these are not new requirements:

   The obfuscated_ticket_age is not used for external PSKs.  As stated
   in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0,
   and servers MUST ignore the value.

>   The selected_identity contains the external PSK identity that the
>   server selected from the list offered by the client.  If none of the
> 
> nit: it's the index of the identity, though it's unclear to what length
> we need to cover that in this document, since RFC 8446 is pretty clear
> and available to the reader in case of confusion.

I think that some context is useful, but I suggest getting rid of some text:

   The selected_identity contains the index of the external PSK identity
   that the server selected from the list offered by the client.  As
   described in Section 4.2.11.2 of [RFC8446], the server MUST validate
   the binder value that corresponds to the selected external PSK, and
   if the binder does not validate, the server MUST abort the handshake
   with an "illegal_parameter" alert.

> 
>                                                            The server
>   MUST validate the binder value that corresponds to the selected
>   external PSK as described in Section 4.2.11.2 of [RFC8446].  If the
>   binder does not validate, the server MUST abort the handshake with an
>   "illegal_parameter" alert.  Servers SHOULD NOT attempt to validate
>   multiple binders; rather they SHOULD select one of the offered
>   external PSKs and validate only the binder that corresponds to that
>   external PSK.
> 
> (This chunk also has pretty high overlap with existing RFC 8446
> requirements.)

Agreed, and I proposed to reduce the repeated text above.

>   TLS 1.3 does not permit the server to send a CertificateRequest
>   message when a PSK is being used.  This restriction is removed when
>   the "tls_cert_with_extern_psk" extension is negotiated, allowing
>   certificate-based authentication for both the client and the server.
> 
> We might get some questions about whether this weakening of an RFC 8446
> requirement requires an "Updates:" relationship (problematic given this
> document is targetting Experimental status), but I don't think it's
> necessary.  (That text is relevant when the server is authenticating
> solely with a PSK, which is not the case here.)

I would argue that it is not a "weakening" for exactly this reason.  The TLS WG wanted to move forward with an Experimental RFC, so I assume that it cannot update RFC 8446.

>   Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule.  The
>   successful negotiation of the "tls_cert_with_extern_psk" extension
>   requires the key schedule processing to include both the external PSK
>   and the (EC)DHE shared secret value.
> 
> Do we want to say "into the PSK and (EC)DHE inputs, respectively"?  It
> seems almost banal to do so, so maybe not...

There are only two variable inputs, and then text says to "include both", so I am not sure how "respectively" adds clarity.

>   If the client and the server have different values associated with
>   the selected external PSK identifier, then the client and the server
>   will compute different values for every entry in the key schedule,
>   which will lead to the termination of the connection with a
>   "decrypt_error" alert.
> 
> (side note) this is a case where "abort the handshake" would be
> appropriate, though the verb tense into which we have to fit probably
> makes the current wording better :)

I suggest:

   If the client and the server have different values associated with
   the selected external PSK identifier, then the client and the server
   will compute different values for every entry in the key schedule,
   which will lead to the client aborting the handshake with a
   "decrypt_error" alert.

> Section 6
> 
> We also should probably say that it gets the "Recommended" value "N"
> (not that we have any choice about it) and [this document] is the
> reference.

I suggest:

   IANA is requested to update the TLS ExtensionType Registry to include
   "tls_cert_with_extern_psk" with a value of TBD and the list of
   messages "CH, SH" in which the "tls_cert_with_extern_psk" extension
   may appear.

>   Implementations must protect the external pre-shared key (PSK).
>   Compromise of the external PSK will make the encrypted session
>   content vulnerable to the future invention of a large-scale quantum
>   computer.
> 
> ("invention" and "large-scale quantum computer" again, if we end up
> making a pass to change either of those)

I changed it to "development" as above.

>   Implementers should not transmit the same content on a connection
>   that is protected with an external PSK and a connection that is not.
>   Doing so may allow an eavesdropper to correlate the connections,
>   making the content vulnerable to the future invention of a large-
>   scale quantum computer.
> 
> I think I'm missing a step here.  While it's clear that if the same
> content is sent on two connections, and the attacker can correlate the
> connections so as to know that fact, then the PSK-less connection can be
> attacked with the quantum computer and thus reveal the contents of the
> PSK-protected connection, I'm not sure how just having the same content
> on the two connection allows the eavesdropper to correlate the
> connections.  Or is this just a more generic risk (e.g., timing/size
> analysis) that's not particularly enabled by the external PSK
> (non-)usage?

The point is more straightforward than the correlation.  if the content requires protection from the future development of a large-scale quantum computer, then sending it on a connection with external PSK protection and one without external PSK protection leave the content vulnerable.

>   If the external PSK is known to any party other than the client and
>   the server, then the external PSK MUST NOT be the sole basis for
>   authentication.  The reasoning is explained in [K2016] (see
>   Section 4.2).  When this extension is used, authentication is based
>   on certificates, not the external PSK.
> 
> Are we talking about [K2016] as https://eprint.iacr.org/2016/711.pdf ?
> I failed to find anything in Section 4.2 that considers the case when
> the PSK is shared between more parties than just C and S.

Yes.  Footnote 6 says it, but you need a lot of context from earlier in the paper to get the full consequences of that short statement.

If you are aware of another reference that explains the situation, I'll be glad to take a look.

>   1.2 PRF.  Thus, the safest approach is to use a PSK with either TLS
>   1.2 or TLS 1.3.  However, any PSK that might be used with both TLS
>   1.2 and TLS 1.3 must be used with only one hash function, which is
>   the one that is bound for use in TLS 1.3.  This restriction is less
> 
> nit(?): I suggest rewording "use a PSK with either TLS 1.2 or TLS 1.3",
> as the current wording can be confusing as to the exclusive nature of
> the "or", perhaps to "the safest approach is to use any given PSK with
> at most one of TLS 1.2 and TLS 1.3".

I suggest:

   ... Thus, the safest approach is to use a PSK exclusively with
   TLS 1.2 or exclusively with TLS 1.3.  ...

> What is the origin of the "only one hash function" requirement?

Section 4.2.11 of RFC 8446 says:

   Each PSK is associated with a single Hash algorithm.  For PSKs
   established via the ticket mechanism (Section 4.6.1), this is the KDF
   Hash algorithm on the connection where the ticket was established.
   For externally established PSKs, the Hash algorithm MUST be set when
   the PSK is established or default to SHA-256 if no such algorithm is
   defined.  The server MUST ensure that it selects a compatible PSK
   (if any) and cipher suite.

{{Note the wording that you expect the IESG to complain about.}}

> (Appendix E.7 of RFC 8446 only has this limitation apply to the TLS 1.3
> usage, not the TLS 1.2 usage.)

Observe that draft-ietf-tls-external-psk-importer is a way to handle this situation.  Given a PSK, one can derive another PSK for use with TLS 1.2 and a different one for use with TLS 1.3.

>   than optimal when users want to provision a single PSK.  While the
>   constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC
>   [RFC2104], the constructions are different, and there is no known way
>   in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would
>   produce related outputs.
> 
> (This also has pretty high overlap with Appendix E.7 of RFC 8446; do we
> need to inline it all as opposed to incorporating by reference?)

I agree, and now that draft-ietf-tls-external-psk-importer is available, I can suggest a way to handle the situation instead of just warning about it:

   TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are
   bound to a specific hash function and KDF.  By contrast, TLS 1.2
   [RFC5246] allows PSKs to be used with any hash function and the TLS
   1.2 PRF.  Thus, the safest approach is to use a PSK exclusively with
   TLS 1.2 or exclusively with TLS 1.3.  Given one PSK, one can derive a
   PSK for exclusive use with TLS 1.2 and derive another PSK for
   exclusive use with TLS 1.3 using the mechanism specified in
   [I-D.ietf-tls-external-psk-importer].

Thanks,
  Russ