jiebi/TextFlow huggingface dataset:
Original text:
<<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>.  For example, the key ID "basement" authenticating using Ed25519 ED25519 could produce the following header field (lines are folded to fit):

Reviewer comments:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Revised text:
<<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. <ins> 4.4. The REQUIRED "v" (verification) parameter is a byte sequence that specifies the verification that the user agent provides to attest to possessing the key exporter output.  This avoids issues with signature schemes where certain keys can generate signatures that are valid for multiple inputs (see SEEMS-LEGIT). </ins> For example, the key ID "basement" authenticating using Ed25519 ED25519 could produce the following header field (lines are folded to fit):
Original text:
of 401 (Unauthorized).  Such authentication failures can be caused for example by: * absence of the Authorization field * failure to parse the Authorization field * use of the Signature authentication <del> scheme with an unknown key ID * failure to validate the signature. </del>  Such servers MUST also ensure that the timing of their request handling does not leak any information.  This can be accomplished by

Reviewer comments:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Revised text:
of 401 (Unauthorized).  Such authentication failures can be caused for example by: * absence of the Authorization field * failure to parse the Authorization field * use of the Signature authentication  <ins> scheme with an unknown key ID * failure to validate the verification parameter * failure to validate the signature. </ins> Such servers MUST also ensure that the timing of their request handling does not leak any information.  This can be accomplished by
Original text:
client, then inform the upstream HTTP server of the presence of valid authentication. <del> The intermediary can export the nonce (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. </del>  The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document.

Reviewer comments:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Revised text:
client, then inform the upstream HTTP server of the presence of valid authentication.  <ins> The intermediary can export the nonce and verification (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. </ins> The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document.
Original text:
The key exporter context contains the following fields:  4. This specification defines the following authentication parameters.

Reviewer comments:
From Ilari Liusvaara on the :
I think that I might disagree with Ilari here for this application. Key separation is probably a better model to employ here, though as soon as someone even hints that they might want to share client certificate keys and these keys then this sort of protection probably makes sense.
Briefly mentioned this issue at IETF 116, but did not have time for questions so we asked folks who care to comment on the issue.
Thinking about this some more, prepending a fixed string to the nonce before signing it sounds like it would be pretty cheap and would remove a class of issues - I'm inclined to do that. I'll write up a PR.
OK wrote up to address this

Revised text:
The key exporter context contains the following fields: <ins> 3.3. Once the nonce has been extracted from the key exporter output (see output), it is prefixed with static data before being signed to mitigate issues caused by key reuse.  The signature is computed over the concatenation of: A string that consists of octet 32 (0x20) repeated 64 times The context string "HTTP Signature Authentication" A single 0 byte which serves as a separator The nonce extracted from the key exporter output (see output) For example, if the nonce has all its 32 bytes set to 01, the content covered by the signature (in hexadecimal format) would be: This constructions mirrors that of the TLS 1.3 CertificateVerify message defined in TLS. The resulting signature is then transmitted to the server using the "p" Parameter (see parameter-p). </ins> 4. This specification defines the following authentication parameters.
Original text:
Each algorithm has a status field, which is intended to provide an aid to implementation selection. <del> Algorithms with a status value of "standard" are suitable for many </del>  purposes and it is RECOMMENDED that applications use these algorithms.  These can be used in adversarial situations where hash functions might need to provide resistance to collision, first- preimage and second-preimage attacks.  For adversarial situations, <del> selecting which of the "standard" algorithms are acceptable will depend on the level of protection the circumstances demand.  More </del>  considerations are presented in sec-agility. <del> Algorithms with a status value of "insecure" either provide none of </del>  these properties, or are known to be weak (see NO-MD5 and NO-SHA). These algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial

Reviewer comments:
During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.

Revised text:
Each algorithm has a status field, which is intended to provide an aid to implementation selection.  <ins> Algorithms with a status value of "Active" are suitable for many </ins> purposes and it is RECOMMENDED that applications use these algorithms.  These can be used in adversarial situations where hash functions might need to provide resistance to collision, first- preimage and second-preimage attacks.  For adversarial situations,  <ins> selecting which of the "Active" algorithms are acceptable will depend on the level of protection the circumstances demand.  More </ins> considerations are presented in sec-agility.  <ins> Algorithms with a status value of "Deprecated" either provide none of </ins> these properties, or are known to be weak (see NO-MD5 and NO-SHA). These algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial
Original text:
Such applications are not exempt from the requirements in this section.  Furthermore, applications without such legacy or history ought to follow the guidance for using algorithms with the status <del> value "standard". </del>  Discussion of algorithm agility is presented in sec-agility.

Reviewer comments:
During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.

Revised text:
Such applications are not exempt from the requirements in this section.  Furthermore, applications without such legacy or history ought to follow the guidance for using algorithms with the status  <ins> value "Active". </ins> Discussion of algorithm agility is presented in sec-agility.
Original text:
Status: the status of the algorithm.  The options are: <del> "standard" - for standardized algorithms without known problems, </del>  <del> "provisional" - for non-standard or unproven algorithms, </del>  <del> "insecure" - for insecure algorithms, </del>  Description: a short description of the algorithm

Reviewer comments:
During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.

Revised text:
Status: the status of the algorithm.  The options are:  <ins> "Active" - for algorithms without known problems, </ins>  <ins> "Provisional" - for unproven algorithms, </ins>  <ins> "Deprecated" - for deprecated or insecure algorithms, </ins> Description: a short description of the algorithm
Original text:
pay attention to the requested status.  The status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The <del> "standard" status is not suitable for an algorithm that is known to be weak, broken, or experimental.  If a registration request attempts to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional". </del>  When reviewing registration requests, the designated expert(s) cannot <del> use a status of "insecure" or "provisional" as grounds for rejection. </del>  Requests to update or change the fields in an existing registration are permitted.  For example, this could allow for the transition of <del> an algorithm status from "standard" to "insecure" as the security </del>  environment evolves. 6.

Reviewer comments:
During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.

Revised text:
pay attention to the requested status.  The status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The  <ins> "Active" status is not suitable for an algorithm that is known to be weak, broken, or experimental.  If a registration request attempts to register such an algorithm as "Active", the designated expert(s) should suggest an alternative status of "Deprecated" or "Provisional". </ins> When reviewing registration requests, the designated expert(s) cannot  <ins> use a status of "Deprecated" or "Provisional" as grounds for rejection. </ins> Requests to update or change the fields in an existing registration are permitted.  For example, this could allow for the transition of  <ins> an algorithm status from "Active" to "Deprecated" as the security </ins> environment evolves. 6.
Original text:
4.1. When using this specification in HTTP/2 or HTTP/3, clients MAY start <del> sending TCP stream content without waiting for an HTTP response. Proxies MUST buffer this "false start" content until the TCP stream becomes writable, and discard it if the TCP connection fails.  (This "false start" behavior is not permitted in HTTP/1.1 because it would prevent reuse of the connection after an error response such as 407 (Proxy Authentication Required).) </del>  Servers that host a proxy under this specification MAY offer support for TLS early data in accordance with RFC8470.  Clients MAY send <del> "connect-tcp" requests in early data, and MAY include "false start" content in early data (in HTTP/2 and HTTP/3).  Proxies MAY accept, reject, or delay processing of this early data.  For example, a proxy with limited anti-replay defenses might choose to perform DNS resolution of the "target_host" when a request arrives in early data, but delay the TCP connection until the TLS handshake completes. </del>  4.2.

Reviewer comments:
Within TLS 1.3, the only options for 0-RTT are "accept" or "reject". "accept but delay until after the handshake" is not visible within the TLS 1.3 protocol. The current draft language doesn't align nicely with this, and should be adjusted. Credit: NAME

Revised text:
4.1. When using this specification in HTTP/2 or HTTP/3, clients MAY start  <ins> sending TCP stream content optimistically, subject to flow control limits (RFC9113)(RFC9000).  Proxies MUST buffer this "optimistic" content until the TCP stream becomes writable, and discard it if the TCP connection fails.  (This "optimistic" behavior is not permitted in HTTP/1.1 because it would prevent reuse of the connection after an error response such as "407 (Proxy Authentication Required)".) </ins> Servers that host a proxy under this specification MAY offer support for TLS early data in accordance with RFC8470.  Clients MAY send  <ins> "connect-tcp" requests in early data, and MAY include "optimistic" TCP content in early data (in HTTP/2 and HTTP/3).  At the TLS layer, proxies MAY ignore, reject, or accept the "early_data" extension (RFC8446).  At the HTTP layer, proxies MAY process the request immediately, return a "425 (Too Early)" response (RFC8470), or delay some or all processing of the request until the handshake completes. For example, a proxy with limited anti-replay defenses might choose to perform DNS resolution of the "target_host" when a request arrives in early data, but delay the TCP connection until the TLS handshake completes. </ins> 4.2.
Original text:
Append "%" to encoded_string. Let encoded_byte be the result of applying base16 encoding <del> (Section 8 of RFC4648) to byte. </del>  Append encoded_byte to encoded_string.

Reviewer comments:
Can I suggest we use 'converted' instead of 'normalized' ?
WFM, will update.
It's annoying to test for otherwise. Still allow both cases in parse.
Postel's law ("Be liberal in what you accept, and conservative in what you send.") isn't as popular these days as it once was. Not sure we need to accept upper case % anymore.
I am sure that we don’t. (Though I have thoughts on the use of the Robustness Principle to guide this sort of decision. Generally, it is better to look at what the case needs. Here, the values are created by code, so permissiveness is not a valuable feature.)
Fine. See URL

Revised text:
Append "%" to encoded_string. Let encoded_byte be the result of applying base16 encoding  <ins> (Section 8 of RFC4648) to byte, with any alphabetic characters converted to lowercase. </ins> Append encoded_byte to encoded_string.
Original text:
input_string.  If there are not two characters, fail parsing.  Let octet be the result of hex decoding octet_hex (Section 8 <del> of RFC4648), in a case-insensitive fashion.  If decoding fails, fail parsing. </del>  Append octet to byte_array.

Reviewer comments:
Can I suggest we use 'converted' instead of 'normalized' ?
WFM, will update.
It's annoying to test for otherwise. Still allow both cases in parse.
Postel's law ("Be liberal in what you accept, and conservative in what you send.") isn't as popular these days as it once was. Not sure we need to accept upper case % anymore.
I am sure that we don’t. (Though I have thoughts on the use of the Robustness Principle to guide this sort of decision. Generally, it is better to look at what the case needs. Here, the values are created by code, so permissiveness is not a valuable feature.)
Fine. See URL

Revised text:
input_string.  If there are not two characters, fail parsing. <ins> If octet_hex contains characters outside the range %x30-39 or %x61-66 (i.e., it is not in 0-9 or lowercase a-f), fail parsing. </ins> Let octet be the result of hex decoding octet_hex (Section 8  <ins> of RFC4648). </ins> Append octet to byte_array.
Original text:
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses <del> TLS, such as "h2" RFC7540, or "http/1.1" RFC7301.  Note that HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of RFC7230). </del>  A client that receives such an advertisement MAY make future requests <del> intended for the associated origin (RFC6454) to the identified service (as specified by RFC7838), provided that the alternative service opts in as described in auth. </del>  A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an

Reviewer comments:
I tried to make this work, but NAME is right: this is entirely a transport decision and given that our best option was to violate a MUST in RFC 7230, that's too hard. This just says that HTTP/1.1 is no good because we can't include the scheme (because RFC 7230 says we can't). I almost made this h2-specific, but then remembered that there might be another protocol that has favourable properties.
It's official - MT says "HTTP/1.1 is no good."

Revised text:
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses  <ins> TLS, such as "h2" RFC7540.  Such a protocol MUST include an explicit indication of the scheme of the resource.  This excludes HTTP/1.1; HTTP/1.1 clients are forbidden from including the absolute form of a URI in requests to origin servers (see Section 5.3.1 of RFC7230). </ins> A client that receives such an advertisement MAY make future requests  <ins> intended for the associated origin RFC6454 to the identified service (as specified by RFC7838), provided that the alternative service opts in as described in opt-in. </ins> A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an
Original text:
to determine if a request is for an "https" resource; for example, they might look for TLS on the stack, or a server port number of 443. <del> This might be due to limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme), or it may be because how the server and application are </del>  implemented (often, they are two separate entities, with a variety of possible interfaces between them).

Reviewer comments:
I tried to make this work, but NAME is right: this is entirely a transport decision and given that our best option was to violate a MUST in RFC 7230, that's too hard. This just says that HTTP/1.1 is no good because we can't include the scheme (because RFC 7230 says we can't). I almost made this h2-specific, but then remembered that there might be another protocol that has favourable properties.
It's official - MT says "HTTP/1.1 is no good."

Revised text:
to determine if a request is for an "https" resource; for example, they might look for TLS on the stack, or a server port number of 443.  <ins> This might be due to expected limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme and the resource might have been developed assuming HTTP/1.1), or it may be because how the server and application are </ins> implemented (often, they are two separate entities, with a variety of possible interfaces between them).
Original text:
The "ttl" value is optional and defaults to 31536000 (1 year). <del> 2.1.3. </del>  The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Reviewer comments:
This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,

Revised text:
The "ttl" value is optional and defaults to 31536000 (1 year).  <ins> 2.1.5. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.