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

[Benjamin Kaduk <[e-mail]>]

Hi all,

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

   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?

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

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

   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.

   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.

   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.

Section 5

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

   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.

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


   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.

   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?

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

   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.

   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?)

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

   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.

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

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

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

   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 :)

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.

   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)

   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?

   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.

   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".
What is the origin of the "only one hash function" requirement?
(Appendix E.7 of RFC 8446 only has this limitation apply to the TLS 1.3
usage, not the TLS 1.2 usage.)

   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?)

Thanks,

Ben