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

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 9 Nov 2019 16:43:35 -0800

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

---

From: Russ Housley <[email-masked]>
Date: Sun, 10 Nov 2019 15:41:44 -0500

Ben:

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

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

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

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

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

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

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

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

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

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

> (This is another MUST that duplicates an existing requirement from RFC

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.

> extension in the EncryptedExtensions since it affects what key is used

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.

> This seems redundant with the requirements from Section 4; is the

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.

> versions of the requirements (without normative keywords).

Okay.  This one was deleted.

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

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

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

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

> (This chunk also has pretty high overlap with existing RFC 8446

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

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

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

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

> (not that we have any choice about it) and [this document] is the

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.

> making a pass to change either of those)

I changed it to "development" as above.

> analysis) that's not particularly enabled by the external PSK

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.

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

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

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

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 12 Nov 2019 18:50:26 -0800

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

I'm happy to approve a manual posting sooner if you want, though I do not
think it would have a huge impact on time-to-end-of-IETF-LC.

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

Understood, and thanks.

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

(I grabbed the RFC 7748 reference from RFC 8446, too.)

>    scale quantum computer becomes available.

Okay, that should work.

>    the last extension in the ClientHello message.

Thanks.

>    all depend upon the value of the selected external PSK.

Thanks, I agree that it is an improvement.

>     the (EC)DHE shared secret.

Thanks!

>    be set when the PSK is established, with a default of SHA-256.

I'm happy to go forward with it, but cannot guarantee it will pass IESG
review.

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

Thanks.  I didn't get a chance to think very hard about what groupings
might make sense.

>    "insufficient_security" alert.

I think that's still talking about the server responding to a ClientHello.

To be clear, I only called it out because the current text begins with "any
other message", which is (to me, at least) calling out NewSessionTicket,
CertificateRequest, and friends.

>    message or abort the handshake.

Thanks

>    extension in the ClientHello message.

Thanks.  I might (but might not) s/Therefore/Accordingly/, since we don't
do much to present an argument about when/whether to have the server send
the extension, just which message it goes in when it is sent.

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

Cool, thanks.

>    message, clients MUST include psk_dhe_ke mode.  In addition, clients

nit: "the psk_dhe_ke mode"

>    MAY also include psk_ke mode to support a subsequent

nit: missing "the" again

>    that include the resumption PSK from the initial handshake.

but I appreciate the addition; thanks!

>    abort the handshake with an "illegal_parameter" alert.

Works for me.

>    and servers MUST ignore the value.

Thanks.

>    with an "illegal_parameter" alert.

Looks good.

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

Agreed.

>    which will lead to the client aborting the handshake with a

Excellent, thanks.

>    messages "CH, SH" in which the "tls_cert_with_extern_psk" extension

I think you copied the OLD text and not the NEW, but am confident that your
NEW is something reasonable.

> 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 exter…

If that's all you want to say, then why mention correlation at all?
(I assumed the correlation was needed so as to be able to attack the
nominally-PSK-protected connection.)

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

Ah, I failed to read (or even notice?) the footnote.
I don't know of a particular reference, though the result does seem rather
intuitive.

>    TLS 1.2 or exclusively with TLS 1.3.  ...

Works for me.

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

((It's easy to miss things when they're buried in 100-page documents.  Tiny
ones are easier to nitpick.))

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

I agree that there are lots of reasonable-ish ways to handle the situation,
including draft-ietf-tls-external-psk-importer.
I think what I'm really trying to get at is whether this
(version-agnonstic) "must be used with only one hash function" requirement
is coming from some other preexisting document (in which case a reference
thereto seems in order), or whether (the TLS 1.2 part of) it is new to this
document (in which case we might say something about why).

>    [I-D.ietf-tls-external-psk-importer].

Of course, there's always the third path of removing the need to answer the
question at all, which in this case sounds like a fine thing to do :)

Thanks,

Ben