Exported Authenticators in TLS

Summary: Has enough positions to pass.

Benjamin Kaduk Yes

Comment (2021-04-06)
I've made some (mostl) editorial suggestions in a github PR:

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

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

   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.

Roman Danyliw Yes

Alvaro Retana No Objection

Erik Kline No Objection

Comment (2021-04-03)
[ sections 4 & 5 ]

* "SHOULD use a secure with" ->
  "SHOULD use a secure communications channel with" or
  "SHOULD use a secure transport with" or something?

* "as its as its" -> "as its"

[ section 5.2.3 ]

* I think the first sentence of the first paragraph may not be a
  grammatically complete sentence?

[ section 7 ]

* "following sections describes APIs" ->
  "following sections describe APIs"

Francesca Palombini No Objection

Comment (2021-04-04)
Thank you for the work on this document, and thank you to the doc shepherd for the in-depth background. Please find some comments below.


1. -----

   TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED
   to implement the mechanisms described in this document.

FP: Does this mechanism applies to DTLS as well? The sentence above, the normative reference to DTLS 1.2, and the IANA section 8.2 would imply so. However, this is the only time DTLS is mentioned in the body of the document, excluding IANA considerations. I would like it to be made explicit that this mechanism can be used for DTLS (if that's the case) both in the abstract and in the introduction, add any useful considerations about using this mechanism with DTLS vs TLS, and possibly add a sentence in the introduction stating that DTLS 1.X uses what specified for TLS 1.X. Two examples of why that would be useful are the following sentences:

   using an exporter as described in Section 4 of [RFC5705] (for TLS
   1.2) or Section 7.5 of [TLS13] (for TLS 1.3).  For TLS 1.3, 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.

which makes it clear what applies for TLS but not for DTLS.

2. -----

   used to send the authenticator request SHOULD use a secure with
   equivalent security to TLS, such as QUIC [QUIC-TLS], as its as its

FP: What are the implications of not using such a secure transport protocol? Why is it just RECOMMENDED and not MANDATED? 
nits: missing word "use a secure with" ; remove one of the duplicated "as its".
(Note: this text appears again with the same typos for the authenticator in section 5)

3. -----

      extensions (OCSP, SCT, etc.)

FP: Please consider adding informative references.

Lars Eggert No Objection

Comment (2021-04-06)
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 1, paragraph 9, nit:
-    TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED
-                                       -         -
+    TLS (or DTLS) version 1.2 [RFC5246][RFC6347] or later are REQUIRED

Martin Duke No Objection

Comment (2021-03-31)
- I come away from this not being entirely sure if this document applies to DTLS or not. There is the one reference in the intro to DTLS, but it's not in the abstract, nor anywhere else. Assuming that the Sec. 1 reference is not some sort of artifact, the document would benefit from a liberal sprinkling of 's/TLS/(D)TLS' (but this would not apply to every instance)

- If (D)TLS 1.2 is REQUIRED to implement, then does this document not update those RFCs?


- Sec 1. I think you mean Sec 4.2.6 of RFC 8446, not 4.6.3.

- Sec 4 and 5. "use a secure with..." ?

- Sec 4. s/messages structures/message structures

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Comment (2021-04-07)
Why are the SHOULDs in Section 4 only SHOULDs?  Why might an implementer reasonably not do what this says?

Similarly, the SHOULDs in Section 7 seem awkward, as they have little to do with interoperability.

Robert Wilton No Objection

Warren Kumari No Objection

Comment (2021-04-06)
No email
send info

Zaheduzzaman Sarker No Objection

Comment (2021-04-06)
Thanks for the work on this document. I found it well written and I have minor comments and Nits

Comment : 
  * As this document asked for a IANA registration entry with DTLS-OK, hence this mechanism is OK to be used with DTLS. I understand the heavily references to TLS 1.3 as it relay on the mechanisms described there. However, I found it odd not find any reference to DTLS1.3 (we had it on the last formal IESG telechat, it is quite ready to be referenced). Is this intentional? is it supposed to be that this mechanism defined in this document on can be used with DTLS1.2? 

  * Section 7.3 & 7.4: is "active connection" defined somewhere? it would be good if some descriptive texts are added for clarification as done for the other bullets in the same list.

  * For the API considerations I was expecting a API to generate the  certificate_request_context.

 * Post-handshake authentication is not defined in section 4.6.3 of TLS 1.3
 * Section 4 & 5: likely copy paste error -- s/as its as its/as its

Éric Vyncke No Objection

Comment (2021-04-06)
Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,




I am trusting the WG and the responsible AD for ensuring that the specific section in references are the correct ones.

-- Section 2 --
Unsure where the "terminology" part is...

Also, should "Client" and "Server" be defined here ? Reading section 3, I am still unsure whether the "client" and "server" are the "TLS client" and "TLS server" ...

In the same vein, a small figure with all parties involved would be welcome by the reader.

== NITS ==

In some places, 'TLS13' is used as an anchor rather than 'RFC8446'.

Sometimes, the document uses 'octet' and sometimes 'bytes'.

-- Section 1 --
Spurious '.' in the last §.

-- Section 4 --
"as its as its" ?

John Scudder No Record