Draft: draft-ietf-tls-exported-authenticator

Commentary: Add new " authenticator request " message Make Certificate selection more explicit ( including extensions ) Update API considerations accordingly 
 I update the draft in response to the comments . 
 Two small comments : Can you add text explaining why authenticator requests are not encrypted with handshake keys ? ( Are they encrypted at all ? ) It might help to include a sequence diagram or two showing intended uses of exported authenticators , e.g. , for  's draft , and where requests fit into TLS connections . 
 I 'm not sure what purpose encrypting them would serve . The draft does say that " The application layer protocol used to send the authenticator SHOULD use TLS as its underlying transport . " In other words , the messages have integrity built - in and any desire for confidentiality is the app 's to solve . 
 I was referring to the following sentence : " This message is not encrypted with a handshake key , which differs from how this message is used in TLS 1.3 . " Perhaps you could add text explaining why this choice was made ? 
 By the time you use this , handshake keys might be long gone . I think that we could avoid this confusion by stating that this is only the handshake messages and not records that form the authenticator . And maybe add that because there are no records , there is no record protection .
The authenticator request is a structured message that can be
exported from either party of a TLS connection.  It can be
transmitted to the other party of the TLS connection at the
application layer.  The application layer protocol used to send the
authenticator SHOULD use TLS as its underlying transport.
An authenticator request message can be constructed by either the
client or the server.  This authenticator uses the CertificateRequest
message structure from Section 4.3.2 of TLS13.  This message is not
encrypted with a handshake key, which differs from how this message
is used in TLS 1.3.
This message is used to define the parameters in a request for an
authenticator.
An opaque string which identifies the certificate request and
which will be echoed in the authenticator message.  The
certificate_request_context MUST be unique within the scope of
this connection (thus preventing replay of authenticators).  The
certificate_request_context SHOULD be chosen to be unpredictable
to the peer (e.g., by randomly generating it) in order to prevent
an attacker who has temporary access to the peer's private key
from pre-computing valid authenticators.
The extensions that are allowed in this structure include the
extensions defined for CertificateRequest messages defined in
Section 4.2. of TLS13 and the server_name RFC6066 extension, which
is allowed for client-generated authenticator requests.
An authenticator message can be constructed by either the client or
the server given an established TLS connection, a certificate, and a
corresponding private key.  This authenticator uses the message
structures from Section 4.4 of TLS13, but different parameters.
Also, unlike the Certificate and CertificateRequest messages in TLS
handshake key.
An authenticator message can be constructed by either the client or
the server given an established TLS connection, a certificate, and a
corresponding private key.  For clients, an authenticator request is
required; for servers an authenticator request is optional.  The
authenticator uses the message structures from Section 4.4 of TLS13,
but different parameters.  Unlike the Certificate and
CertificateVerify messages in TLS 1.3, the messages described in this
document are not encrypted with a handshake key.
The certificate message contains an opaque string called
certificate_request_context.  The format of
certificate_request_context is defined by the application layer
protocol and its value can be used to differentiate exported
authenticators.  For example, the application may use a sequence
number used by the higher-level protocol during the transport of the
authenticator to the other party.  Using a unique and unpredictable
value ties the authenticator to a given context, allowing the
application to prevent authenticators from being replayed or
precomputed by an attacker with temporary access to a private key.
The certificate message contains an opaque string called
certificate_request_context, which is extracted from the
authenticator request if present.  If no authenticator request is
provided, it is zero-length.
The algorithm field specifies the signature algorithm used (see
Section 4.2.3 of TLS13 for the definition of this field).  The
signature is a digital signature using that algorithm.  The signature
scheme MUST be a valid signature scheme for TLS 1.3.  This excludes
all RSASSA-PKCS1-v1_5 algorithms and ECDSA algorithms that are not
supported in TLS 1.3.  If an authenticator request is present, the
signature algorithm MUST be chosen from one of the signature schemes
in the authenticator request.  Otherwise, the signature algorithm
used should be chosen from the "signature_algorithms" extension of
the ClientHello used in the connection handshake.
The value Hash(Handshake Context || Certificate) where Hash is the
hash function for the handshake.
A HMAC over the value Hash(Handshake Context || Certificate ||
CertificateVerify) where Hash is the hash function for the
handshake, and the HMAC is computed using the hash function from
the handshake and the Finished MAC Key as a key.
The certificates used in the Certificate message MUST conform to the
requirements of a Certificate message in the version of TLS
negotiated.  This is described in Section 4.2.3 of TLS13 and Sections
7.4.2 and 7.4.6 of RFC5246.  Alternative certificate formats such as
RFC7250 Raw Public Keys are not supported.
A given exported authenticator can be validated by checking the
validity of the CertificateVerify message and recomputing the
Finished message to see if it matches.
The creation and validation of exported authenticators SHOULD be
implemented inside TLS library even if it is possible to implement it
at the application layer.  TLS implementations supporting the use of
exported authenticators MUST provide application programming
interfaces by which clients and servers may request and verify
exported authenticator messages.
The API returns the exported authenticator as output.
In order for the application layer to be able to choose the
certificates and signature schemes to use when constructing an
authenticator, a TLS server SHOULD expose an API that returns the
content of the signature_algorithms extension of client's ClientHello
message.
where Hash is the hash function for the handshake.
A HMAC over the value Hash(Handshake Context || Certificate ||
CertificateVerify) if an authenticator is present, or
Hash(Handshake Context || authenticator request || Certificate ||
CertificateVerify) where Hash is the hash function for the
handshake, and the HMAC is computed using the hash function from
the handshake and the Finished MAC Key as a key.
The certificates chosen in the Certificate message MUST conform to
the requirements of a Certificate message in the version of TLS
negotiated.  If an authenticator request is present, the signature
algorithms used to choose the algorithm are taken from the
"signature_algorithms" in the from the authenticator.  If there is no
authenticator request, the signature algorithms are chosen from the
"signature_algorithms" extension from the ClientHello used in the
connection.  This is described in Section 4.2.3 of TLS13 and Sections
7.4.2 and 7.4.6 of RFC5246.  Alternative certificate formats such as
RFC7250 Raw Public Keys are not supported.  The "server_name"
RFC6066, "certificate_authorities" (Section 4.2.4. of TLS13), or
"oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide
certificate selection, with the extensions provided in the
authenticator request taking precedence over the extensions provided
in the connection handshake.
If an authenticator request was provided, the Certificate message
MUST contain only extensions present in the authenticator request.
Otherwise, the Certificate message MUST contain only extensions
present in the ClientHello.
A given authenticator can be validated by checking the validity of
the CertificateVerify message given the authenticator request (if
used) and recomputing the Finished message to see if it matches.
The creation and validation of both authenticator requests and
authenticators SHOULD be implemented inside the TLS library even if
it is possible to implement it at the application layer.  TLS
implementations supporting the use of exported authenticators MUST
provide application programming interfaces by which clients and
servers may request and verify exported authenticator messages.
It returns an authenticator request, which is a sequence of octets
that includes a CertificateRequest message.
It returns the certificate_request_context.
It returns the exported authenticator as output.  It is RECOMMENDED
that the logic for selecting the certificates and extensions to
include in the exporter is implemented in the TLS library.
Implementing this in the TLS library lets the implementer take
advantage of existing extension and certificate selection logic.
It is also possible to implement this API outside of the TLS library
using TLS exporters.  This may be preferable in cases where the
application does not have access to a TLS library with these APIs or
when TLS is handled independently of the application layer protocol.
It returns the certificate chain and extensions.