(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-exported-authenticator-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

in the existing registration for:

Value: 0
Extension Name: server_name

the entry for TLS 1.3 will be changed from:

CH, EE

to:

CH, EE, CR

As this document requests modifications to existing registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS ExtensionType Values have asked that you send a review request to the <tls-reg-review@ietf.org> mailing list. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the TLS Exporter Labels registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

three new registrations are to be made as follows:

Value: EXPORTER-server authenticator handshake context
DTLS-OK:
Recommended:
Reference: [ RFC-to-be ]
Note:

Value: EXPORTER-client authenticator finished key
DTLS-OK:
Recommended:
Reference: [ RFC-to-be ]
Note:

Value: EXPORTER-server authenticator finished key
DTLS-OK:
Recommended:
Reference: [ RFC-to-be ]
Note:

IANA Question --> What should be the entries for DTLS-OK and Recommended for each of these three new registrations?

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS Exporter Labels have asked that you send a review request to the <tls-reg-review@ietf.org> mailing list. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-07-16):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-ietf-tls-exported-authenticator@ietf.org, christopherwood07@gmail.com, tls-chairs@ietf.org, Sean Turner <sean@sn3rd.com>, Christopher Wood <christopherwood07@gmail.com>, tls@ietf.org, kaduk@mit.edu
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-tls-exported-authenticator-09.txt> (Exported Authenticators in TLS) to Proposed Standard

The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Exported Authenticators in TLS'
  <draft-ietf-tls-exported-authenticator-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-07-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

  This document describes a mechanism in Transport Layer Security (TLS)
  to provide an exportable proof of ownership of a certificate that can
  be transmitted out of band and verified by the peer.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ballot/

No IPR declarations have been submitted directly on this I-D.

Summary

Christopher Wood is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response  comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes.

EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets.

The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates.

Review and Consensus

Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through two WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC.

Intellectual Property

The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

Other Considerations

EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03
[2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf
[3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00

Summary

Christopher Wood is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response  comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes.

EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets.

The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates.

Review and Consensus

Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through two WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC.

Intellectual Property

The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

Other Considerations

EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03
[2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf
[3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00

Summary

Christopher Wood is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response  comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes.

EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets.

The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates.

Review and Consensus

Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through two WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC.

Intellectual Property

The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

Other Considerations

EAs have been implemented by at least two independent parties. No browser has yet implemented the mechanism yet.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03
[2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf
[3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00