[TLS] Benjamin Kaduk's Yes on draft-ietf-tls-exported-authenticator-14: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.