Draft: draft-ietf-tls-exported-authenticator

Commentary: I the line and the reference in the normative section .
Post-handshake authentication is defined in TLS 1.3, but it has the
disadvantage of requiring additional state to be stored as part of
the TLS state machine.  Furthermore, the authentication boundaries of
TLS 1.3 post-handshake authentication align with TLS record
boundaries, which are often not aligned with the authentication
boundaries of the higher-layer protocol.  For example, multiplexed
connection protocols like HTTP/2 RFC7540 do not have a notion of
which TLS record a given message is a part of.
TLS (or DTLS) version 1.2 or later are REQUIRED to implement the
mechanisms described in this document.
Post-handshake authentication is defined in section 4.6.3 of TLS 1.3
TLS13, but it has the disadvantage of requiring additional state to
be stored as part of the TLS state machine.  Furthermore, the
authentication boundaries of TLS 1.3 post-handshake authentication
align with TLS record boundaries, which are often not aligned with
the authentication boundaries of the higher-layer protocol.  For
example, multiplexed connection protocols like HTTP/2 RFC7540 do not
have a notion of which TLS record a given message is a part of.
TLS (or DTLS) version 1.2 RFC5246 RFC6347. or later are REQUIRED to
implement the mechanisms described in this document.
The authenticator request is a structured message that can be created
by either party of a TLS connection using data exported from that
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 request SHOULD use TLS as its
underlying transport to keep the request confidential.  The
application MAY use the existing TLS connection to transport the
authenticator.
The authenticator request is a structured message that can be created
by either party of a TLS connection using data exported from that
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 request SHOULD use a secure with
equivalent security to TLS, such as QUIC QUIC-TLS, as its as its
underlying transport to keep the request confidential.  The
application MAY use the existing TLS connection to transport the
authenticator.
The authenticator 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 or a protocol with comparable security properties as its
underlying transport to keep the Certificate confidential.  The
application MAY use the existing TLS connection to transport the
authenticator.
The authenticator 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
a secure with equivalent security to TLS, such as QUIC QUIC-TLS, as
its as its underlying transport to keep the authenticator
confidential.  The application MAY use the existing TLS connection to
transport the authenticator.
If an authenticator request is present, the signature algorithm MUST
be chosen from one of the signature schemes present in the
authenticator request.  Otherwise, the signature algorithm used
should be chosen from the "signature_algorithms" sent by the peer in
the ClientHello of the TLS handshake.  If there are no available
signature algorithms, then no authenticator should be constructed.
If an authenticator request is present, the signature algorithm MUST
be chosen from one of the signature schemes present in the
authenticator request.  Otherwise, with spontaneous server
authentication, the signature algorithm used MUST be chosen from the
"signature_algorithms" sent by the peer in the ClientHello of the TLS
handshake.  If there are no available signature algorithms, then no
authenticator should be constructed.
IANA is requested to update the entry for server_name(0) in the
registry for ExtensionType (defined in TLS13) by replacing the value
in the "TLS 1.3" column with the value "CH, EE, CR".
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".
When validating an authenticator, a constant-time comparison should
be used.
IANA is requested to update the entry for server_name(0) in the
registry for ExtensionType (defined in TLS13) by replacing the value
in the "TLS 1.3" column with the value "CH, EE, CR" and this document
in the "Reference" column.
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 "DTLS-OK" and
"Recommended" set to "Y" and this document added to the "Reference"
column.