Change:
NAME are you happy with the adjusted text? I don't consider DTLS support to be a big change since the only thing we are relying on from TLS is the exporter interface.
I think that this is sneaking in a big change with the DTLS thing. I'll try to find the email...

Discussion:
1. This document provides a way to authenticate one party of a Transport <del> Layer Security (TLS) communication to its peer using a certificate after the session has been established.  This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed.  This proof of authentication can be exported and transmitted out of band from one party to be validated by its peer. </del> <ins> Layer Security (TLS) connection to its peer using a certificate after the session has been established.  This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed.  This proof of authentication can be exported and transmitted out-of-band from one party to be validated by its peer. </ins> This mechanism provides two advantages over the authentication that TLS natively provides:

connection protocols like HTTP/2 RFC7540 do not have a notion of which TLS record a given message is a part of. <del> For simplicity, the mechanisms described in this document require a TLS version 1.2 or later. </del> <ins> Exported Authenticators are meant to be used as a building block for application protocols.  Mechanisms such as those required to advertise support and handle authentication errors are not handled at the TLS layer. For simplicity, the mechanisms described in this document require TLS (or DTLS) version 1.2 or later. </ins> 2.

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 <del> used to send the authenticator SHOULD use TLS as its underlying transport to keep the request confidential. </del> <ins> 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. </ins> An authenticator request message can be constructed by either the client or the server.  This authenticator request uses the

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 to keep the certificate confidential. <ins> The application MAY use the existing TLS connection to transport the authenticator. </ins> An authenticator message can be constructed by either the client or the server given an established TLS connection, a certificate, and a

4.1. Each authenticator is computed using a Handshake Context and Finished <del> MAC Key derived from the TLS session.  These values are derived using an exporter as described in RFC5705 (for TLS 1.2) or TLS13 (for TLS 1.3).  These values use different labels depending on the role of the sender: </del> <ins> MAC Key derived from the TLS connection.  These values are derived using an exporter as described in RFC5705 (for TLS 1.2) or TLS13 (for TLS 1.3).  These values use different labels depending on the role of the sender: </ins> The Handshake Context is an exporter value that is derived using the label "EXPORTER-client authenticator handshake context" or