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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls