jiebi/TextFlow huggingface dataset:
Original text:
are supported by the server. Since network addresses may change, a client SHOULD NOT assume that <del> extended token lengths are supported by a server later than 60 minutes after receiving the most-recent response with an extended token length. </del>  If a server supports extended token lengths but receives a request with a token of a length it is unwilling or unable to handle, it MUST

Reviewer comments:
This pull request tries to motivate why ~60min is about right.
section 2.2.2: doc> Since network addresses may change, a client SHOULD NOT assume that doc> extended token lengths are supported by a server later than 60 doc> minutes after receiving the most-recent response with an extended doc> token length. 60 minutes for address changes? Out of curiosity, upon what was this based? I lack a good deal of context, but this kind of feels like the kind of constant that will get baked into code and come to govern some behaviour that later might need updating.
The number indeed sounds arbitrary. We could make use of the parameter mechanics that RFC 7252 has (ACK_TIMEOUT and friends) and set the default to 1800 s.

Revised text:
are supported by the server. Since network addresses may change, a client SHOULD NOT assume that  <ins> extended token lengths are supported by a server for an unlimited duration.  Unless additional information is available, the client should assume that addresses (and therefore extended token lengths) are valid for a minimum of 1800s, and for a maximum of 86400s (1 day).  A client may use additional forms of input into this determination.  For instance a client may assume a server which is in the same subnet as the client has a similiar address lifetime as the client.  The client may use DHCP lease times or Router Advertisements to set the limits.  For servers which is not local, if the server was looked up using DNS, then the DNS resource record will have a Time To Live, and the extended token length should be kept for only that amount of time. </ins> If a server supports extended token lengths but receives a request with a token of a length it is unwilling or unable to handle, it MUST
Original text:
appropriate.  In the absence of integrity and reply protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could <del> alter the internal state of the client.  However, a careful analysis of any potential attacks to the security and privacy properties of the system might reveal that there are cases where such cryptographic protections do not add value in a specific case. </del>  RFC3610 with a 64-bit tag is RECOMMENDED, combined with a sequence number and a replay window.  Where encryption is not needed, RFC6234,

Reviewer comments:
… into more positive language
[[TODO]]
Not sure I follow the 5077 analogy. Do we ever plan to use stateless without some integrity protection? We might save a lot of weasel-wording by simply requiring it.

Revised text:
appropriate.  In the absence of integrity and reply protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could  <ins> alter the internal state of the client.  It is this reason that at least the use of integrity protection on the token is always recommended. It maybe that in some very specific case, as a result of a careful and detailed analysis of any potential attacks, that there may be cases where such cryptographic protections do not add value.  The authors of this document have not found such a use case as yet. </ins> RFC3610 with a 64-bit tag is RECOMMENDED, combined with a sequence number and a replay window.  Where encryption is not needed, RFC6234,
Original text:
encryption is not needed, RFC6234, combined with a sequence number and a replay window, may be used.  When using an encryption mode that depends on a nonce, such as AES- CCM, repeated use of the same nonce under the same key causes the cipher to fail catastrophically.

Reviewer comments:
This is some advice on how big the replay window needs to be.
doc> a 64 bit tag is recommended, combined with a sequence number and a doc> replay window. Where encryption is not needed, HMAC-SHA-256, doc> combined with a sequence number and a replay window, may be used. [[TODO]]
An absolute timestamp is probably not necessary, as the key should be newly generated on a reboot. A boot-relative timestamp may be enough. The window pretty much becomes the "patience" value -- how long does the client wait for getting its response?

Revised text:
encryption is not needed, RFC6234, combined with a sequence number and a replay window, may be used. <ins> This size of the replay window depends upon the number of outstanding requests that need to be outstanding.  This can be determined from the rate at which new ones are made, and the expected duration in which responses are expected. For instance, given a CoAP ACK_TIMEOUT of 2s, and a request rate of 10 requests/second, any request that is not answered within 2s will be considered to have failed.  Thus at most 20 request can be outstanding at a time, and any convenient replay window larger than 20 will work.  As replay windows are often implemented with a sliding window and a bit, the use of a 32-bit window would be sufficient. For use cases where requests are being relayed from another node, the request rate may be estimated by the total link capacity allocated for that kind of traffic.  An alternate view would consider how many IPv6 Neighbor Cache Entries (NCEs) the system can afford to allocate for this use. </ins> When using an encryption mode that depends on a nonce, such as AES- CCM, repeated use of the same nonce under the same key causes the cipher to fail catastrophically.
Original text:
Edge computing nodes host logical functions relative to: <del> Finding resources, such as compute, storage or data resources; </del>  Authenticating platforms, end devices, functions, data;

Reviewer comments:
This is the example change we went through at the meeting at IETF 106.
We agreed at the F2F. Merging.

Revised text:
Edge computing nodes host logical functions relative to:  <ins> Finding resources, such as compute, network, storage or data resources; </ins> Authenticating platforms, end devices, functions, data;
Original text:
identical, these are two different resources, in two distinct namespaces.  The query parameters can be used to parametrize the resource.  For example, a GET request may use query parameters to request the server to send only certain kind data of the resource (i.e., filtering the

Reviewer comments:
Tweak a bit the message of this: non-resource identifiers are not really part of the REST style, but a system usually needs them and the IETF has good means with URIs, which include URNs, and can be used for such non-resource identifiers (e.g., for physical asset, device, etc.).
We added the terms to the terminology, but should explain a bit more at the end of the URI sections.
Solved in

Revised text:
identical, these are two different resources, in two distinct namespaces. <ins> Some schemes are for URIs with main purpose as identifiers and hence are not dereferencable, e.g., the "urn" scheme can be used to construct unique names in registered namespaces.  In particular the "urn:dev" I-D.ietf-core-dev-urn details multiple ways for generating and representing endpoint identifiers of IoT devices. </ins> The query parameters can be used to parametrize the resource.  For example, a GET request may use query parameters to request the server to send only certain kind data of the resource (i.e., filtering the
Original text:
provide application programming interfaces by which clients and servers may request and verify exported authenticator messages.  Given an established connection, the application SHOULD be able to call the following APIs:

Reviewer comments:
Relaying feedback received: We currently require EMS+TLS 1.2 or TLS 1.3+ in order for the Exported Authenticator API to be validly used. However, the definition of the APIs don't explicitly call out a failure path. We should probably address this. Simplest option would be to add a sentence to the description of each API that it fails if those conditions aren't met.

Revised text:
provide application programming interfaces by which clients and servers may request and verify exported authenticator messages. <ins> Notwithstanding the success cases described below, all APIs MUST fail if: the connection uses a TLS version of 1.1 or earlier, or the connection is TLS 1.2 and the extended master secret RFC7627 was not used </ins> Given an established connection, the application SHOULD be able to call the following APIs:
Original text:
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 <del> provided, it is zero-length. </del>  The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version a signer (either the private key associated with the certificate, or interface to perform private key operation) for each chain <del> an optional authenticator request </del>  It returns the exported authenticator as a sequence of octets.  It is RECOMMENDED that the logic for selecting the certificates and

Reviewer comments:
Make it possible to choose a non-empty certificaterequestcontext when there is no authenticator request. This change introduces the flexibility needed to achieve compound authentication between certificates using a technique called CRC Smuggling, described by Jonathan Hoyland.

Revised text:
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  <ins> provided, the certificate_request_context can be chosen arbitrarily. </ins> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version a signer (either the private key associated with the certificate, or interface to perform private key operation) for each chain  <ins> an optional authenticator request or certificate_request_context (from 0 to 255 bytes) </ins> It returns the exported authenticator as a sequence of octets.  It is RECOMMENDED that the logic for selecting the certificates and
Original text:
an optional authenticator request or certificate_request_context (from 0 to 255 bytes) <del> It returns the exported authenticator as a sequence of octets.  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. </del>  It is also possible to implement this API outside of the TLS library using TLS exporters.  This may be preferable in cases where the

Reviewer comments:
It's also the only use of 2119 language in this section, which is otherwise nicely informative.

Revised text:
an optional authenticator request or certificate_request_context (from 0 to 255 bytes)  <ins> It returns the exported authenticator as a sequence of octets. Ideally, 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. </ins> It is also possible to implement this API outside of the TLS library using TLS exporters.  This may be preferable in cases where the
Original text:
An authenticator message can be constructed by either the client or the server given an established TLS connection, a certificate, and a <del> 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.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </del>  4.1. If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator request.  If there is no authenticator request, the extensions are <del> chosen from the TLS handshake.  That is, the extensions received in a ClientHello (for servers), ServerHello (for clients in TLS 1.2), or EncryptedExtensions (for clients in TLS 1.3). </del>  4.2.1.

Reviewer comments:
In Section 4, clients are required to have an authenticator request before generating and sending an authenticator. Later, in Section 4.2, the draft states that clients may get authenticator information from a SH or EncryptedExtensions in the event that no authenticator request is present. This seems to contradict the requirement in Section 4.

Revised text:
An authenticator message can be constructed by either the client or the server given an established TLS connection, a certificate, and a  <ins> corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional. The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </ins> 4.1. If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator request.  If there is no authenticator request, the extensions are  <ins> chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1.
Original text:
the server given an established TLS connection, a certificate, and a corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an <del> authenticator request is optional. The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </del>  4.1.

Reviewer comments:
the newline was being introduced by trailing whitespace at the end of line 136.
In the , there's a newline between two sentences that apparently can't decide whether they want to be in separate paragraphs or not.

Revised text:
the server given an established TLS connection, a certificate, and a corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an  <ins> authenticator request is optional.  The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </ins> 4.1.
Original text:
The "get context" API takes as input: <del> authenticator </del>  It returns the certificate_request_context.

Reviewer comments:
In the HTTPbis meeting in Montreal, it was suggested that recipients of a frame should validate that the claimed Request-ID matched the in the supplied authenticator request. However, the document defines no API which would permit us to do that.
Shouldn't this be implemented at the HTTP layer using the "get context" API? This document is not prescriptive about the content of the crc except that it is unpredictable and unique.
allows us to extract it from an authenticator, but doesn't allow performing the same operation on a request.
Good point. This should be a simple addition.
URL

Revised text:
The "get context" API takes as input:  <ins> authenticator or authenticator request </ins> It returns the certificate_request_context.
Original text:
The CertificateRequest and ClientCertificateRequest messages are used to define the parameters in a request for an authenticator.  These <del> messages do not include any TLS framing and are not encrypted with a handshake key. </del>  The structures are defined to be: hash is referred to as the authenticator hash. To avoid key synchronization attacks, Exported Authenticators MUST <del> NOT be generated or accepted on TLS 1.2 connectons that did not </del>  negotiate the extended master secret RFC7627. 5.2. An authenticator is formed from the concatenation of TLS 1.3 TLS13 <del> Certificate, CertificateVerify, and Finished messages. </del>  If the peer creating the certificate_request_context has already created or correctly validated an authenticator with the same value, a Certificate message containing no CertificateEntries and the CertificateVerify message omitted.  The HMAC is computed using the authenticator hash, using the Finished MAC Key as a key.  This <del> message does not include any TLS framing. </del>  7.

Reviewer comments:
Proposal to fix Issue
cc NAME
The Introduction limits this to TLS 1.2 and later, but DTLS is similar. Do you want to take that into account now, or ignore it? DTLS has additional fields to support fragmentation: URL URL
Exported authentication are meant to be embedded in a higher-layer protocol, so there's no need to support fragmentation.
The draft states that there should be no "TLS framing" but what is meant is that the handshake messages shouldn't be encapsulated by TLS Record Framing (which does the encryption of the handshake messages).

Revised text:
The CertificateRequest and ClientCertificateRequest messages are used to define the parameters in a request for an authenticator.  These  <ins> are encoded as TLS handshake messages, including length and type fields.  They do not include any TLS record layer framing and are not encrypted with a handshake key. </ins> The structures are defined to be: hash is referred to as the authenticator hash. To avoid key synchronization attacks, Exported Authenticators MUST  <ins> NOT be generated or accepted on TLS 1.2 connections that did not </ins> negotiate the extended master secret RFC7627. 5.2. An authenticator is formed from the concatenation of TLS 1.3 TLS13  <ins> Certificate, CertificateVerify, and Finished messages.  These messages are encoded as TLS handshake messages, including length and type fields. </ins> If the peer creating the certificate_request_context has already created or correctly validated an authenticator with the same value, a Certificate message containing no CertificateEntries and the CertificateVerify message omitted.  The HMAC is computed using the authenticator hash, using the Finished MAC Key as a key.  This  <ins> message is encoded as a TLS handshake message, including length and type field.  It does not include TLS record layer framing. </ins> 7.
Original text:
This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an <del> X509 certificate.  This proof can be exported by one peer, </del>  transmitted out-of-band to the other peer, and verified by the receiving peer. An authenticator message can be constructed by either the client or the server given an established TLS connection, an identity, such as <del> an X509 certificate, and a corresponding private key.  Clients MUST </del>  NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional.  For authenticators that do not correspond to authenticator requests, the "oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide certificate selection. <del> Only the X509 certificate type defined in TLS13 is supported. </del>  Alternative certificate formats such as RFC7250 Raw Public Keys are not supported in this version of the specification and their use in this context has not yet been analysed. Where Hash is the authenticator hash defined in section 4.1.  If the authenticator request is not present, it is omitted from this <del> construction, i.e., it is zero length. </del>  If the party that generates the exported authenticator does so with a different connection than the party that is validating it, then the

Reviewer comments:
got merged while I was reviewing it, so here's my feedback as a follow-up PR. I initially though line 244 needed a comma, but usage through the rest of the document suggests that supporting certificates are a property of one type of identity instead of something that could come along with a generic identity, so I dropped that one.
Thanks, Mike.

Revised text:
This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an  <ins> X.509 certificate.  This proof can be exported by one peer, </ins> transmitted out-of-band to the other peer, and verified by the receiving peer. An authenticator message can be constructed by either the client or the server given an established TLS connection, an identity, such as  <ins> an X.509 certificate, and a corresponding private key.  Clients MUST </ins> NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional.  For authenticators that do not correspond to authenticator requests, the "oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide certificate selection.  <ins> Only the X.509 certificate type defined in TLS13 is supported. </ins> Alternative certificate formats such as RFC7250 Raw Public Keys are not supported in this version of the specification and their use in this context has not yet been analysed. Where Hash is the authenticator hash defined in section 4.1.  If the authenticator request is not present, it is omitted from this  <ins> construction, i.e., it is zero-length. </ins> If the party that generates the exported authenticator does so with a different connection than the party that is validating it, then the
Original text:
an authenticator  It returns the identity, such as the certificate chain and its extensions, and a status to indicate whether the authenticator is <del> valid or not.  The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator.  Well-formed empty authenticators are returned as valid. </del>  8.

Reviewer comments:
one minor nit: i would phrase "applying the function for validating the certificate chain contained in the authenticator." as "applying the function for validating the certificate chain to the chain contained in the authenticator." for clarity. Otherwise LGTM!
I've implemented earlier drafts. I do have a concern with the validate API as presented in the draft: it treats empty authenticators as valid, and then returns the identity as a certificate chain that must be validated by the application. Similar APIs have lead to easily foreseeable pwnage. Instead I would recommend the validate API carry out X509 validation against a trust store or validation function and treat the empty authenticator as invalid. That way someone has to think before not checking the certificate returned.
Closing this out as it was addressed.

Revised text:
an authenticator <ins> a function for validating a certificate chain </ins> It returns the identity, such as the certificate chain and its extensions, and a status to indicate whether the authenticator is  <ins> valid or not after applying the function for validating the certificate chain to the chain contained in the authenticator. The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator. Well-formed empty authenticators are returned as invalid. </ins> 8.