Benjamin Kaduk has entered the following ballot position for draft-ietf-tls-exported-authenticator-14: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've made some (mostl) editorial suggestions in a github PR: https://github.com/tlswg/tls-exported-authenticator/pull/73 Despite the overall YES ballot, I do have some substantive comments that may be worth some further consideration. Do we want to give any insight or examples into how an application might choose to use the certificate_request_context? Thanks to Yaron Sheffer for the multiple secdir reviews. My understanding is that the intent of this document is to only allow "server_name" to appear in the ClientCertificateRequest structure that otherwise uses the "CR" notation in the TLS 1.3 column of the TLS ExtensionType Values registry, but not to allow for "server_name" in authenticator CertificateRequests or handshake CertificateRequests. Assuming that's correct, the easiest way to indicate that would be if there was a "Comment" column in the registry that could say "only used in ClientCertificateRequest certificate requests and no other certificate requests", but there is not such a column in the registry. I think it could also work to be much more clear in the IANA considerations of this document as to why the "CR" is being added and what restrictions there are on its use, even if that's not quite as clean of a solution. Section 1 multiple identities - Endpoints that are authoritative for multiple identities - but do not have a single certificate that includes all of the identities - can authenticate additional identities over a single connection. IIUC this is only new functionality for server endpoints, since client endpoints can use different certificates for subsequent post-handshake authentication events. TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED to implement the mechanisms described in this document. Please clarify whether this is a minimum TLS version required for using EAs, or that this is a binding requirement on implementations of the named protocol versions. (If the latter is intended we may have some discussions about an Updates: tag...) Section 5.1 Using an exporter value as the handshake context means that any client authentication from the initial handshake is not cryptographically digested into the exporter value. In light of what we ran into with EAP-TLS1.3, do we want to revisit whether we're still happy with that? We should in practice still benefit from the implicit confirmation that anything the server participates in after receiving the Client Finished means the server properly validated it and did not abort the handshake, but it's a bit awkward, especially since the RFC 8446 post-handshake authentication does digest the entire initial handshake transcript. Would we feel any safer if an exporter variant was available that digested the entire initial handshake transcript and we could use that? Section 5.2.1 Certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version of TLS. In particular, the certificate chain MUST be valid for the signature algorithms indicated by the peer in the "signature_algorithms" and "signature_algorithms_cert" extension, as described in Section 4.2.3 of [TLS13] for TLS 1.3 or the "signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of [RFC5246] for TLS 1.2. This seems awkward. Do "the requirements of a Certificate message in the negotiated version of TLS" include the actual message structure? Because the rest of the document suggests that we always use the TLS 1.3 Certificate, but this line would set us up for using a TLS 1.2 Certificate. Also, per ยง1.3 of RFC 8446, "signature_algorithms_cert" also applies to TLS 1.2, so the last sentence seems incorrect or at least incomplete. Section 5.2.1 Otherwise, the Certificate message MUST contain only extensions present in the TLS handshake. Unrecognized extensions in the authenticator request MUST be ignored. At least the first sentence seems redundant with the previous section (but I did not propose removing this in my editorial PR). The second sentence arguably follows from the RFC 8446 requirements, though I don't mind mentioning it again as much as I do for the first sentence. Section 5.2.2 The authenticator transcript is the hash of the concatenated Handshake Context, authenticator request (if present), and Certificate message: Hash(Handshake Context || authenticator request || Certificate) Where Hash is the authenticator hash defined in section 4.1. If the authenticator request is not present, it is omitted from this construction, i.e., it is zero-length. This construction is injective, because the handshake messages start with a message HandshakeType. Should we say so explicitly in the document? If the party that generates the exported authenticator does so with a different connection than the party that is validating it, then the Handshake Context will not match, resulting in a CertificateVerify message that does not validate. This includes situations in which the application data is sent via TLS-terminating proxy. Given a failed CertificateVerify validation, it may be helpful for the application to confirm that both peers share the same connection using a value derived from the connection secrets before taking a user-visible action. Is it safe to reuse the Handshake Context itself as the "value derived from the connection secrets"? Section 7.4 It returns the identity, such as the certificate chain and its extensions, and a status to indicate whether the authenticator is valid or not after applying the function for validating the certificate chain to the chain contained in the authenticator. I strongly recommend not returning the identity in the case when validation fails. The API should return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator. Is the intent for this to be a "distinct previously validated authenticator" (i.e., that the API returns the same value when given the same inputs subsequently)? That does not seem to be the meaning conveyed by the current text. Section 8.2 IANA is requested to add the following entries to the registry for Exporter Labels (defined in [RFC5705]): "EXPORTER-server authenticator handshake context", "EXPORTER-client authenticator finished key" and "EXPORTER-server authenticator finished key" with Don't we also need "EXPORTER-client authenticator handshake context"? Section 9 I think we should more explicitly incorporate the TLS 1.3 security considerations by reference. Section 11.1 I don't think [QUIC-TLS] or RFCs 7250 and 7540 are normative references. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
