jiebi/TextFlow huggingface dataset:
Original text:
but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases.  In addition to this media type negotiation, it aligns <del> itself with HTTP features such as caching, proxying, and compression. </del>  The integration with HTTP provides a transport suitable for both traditional DNS clients and native web applications seeking access to 5.  Different response media types will provide more or less information from a DNS response.  For example, one response type might include the information from the DNS header bytes while another might omit

Reviewer comments:
Thats better. Thanks
It would be good to explicitly call out the DNS rcode SERVFAIL as a type of failure response as well, not just NXDOMAIN, as they are very different sorts of failures such that the latter can be considered, in some contexts, as not really a failure.
the merged patch URL no longer mentions specific rcodes at all.. wdyt?
I personally think that as a DNS implementer that there is enough ambiguity around understanding a valid DNS response, a negative answer, and a failure response, that it should be made more painfully clear that something like all DNS servers returning message-valid SERVFAILs still warrants an HTTP 2xx.
Agree with NAME .
will reopen the issue to add more text
largely a restating of mailing list thread: A question on the mix of DNS and HTTP semantics
keep pr but reopen the issue to add a little more text
Liked Martin's rewording for the response text, but removed the security considerations until further discussion. Patrick, please edit or pull.

Revised text:
but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases.  In addition to this media type negotiation, it aligns  <ins> itself with HTTP features such as caching, redirection, proxying, and compression. </ins> The integration with HTTP provides a transport suitable for both traditional DNS clients and native web applications seeking access to 5. <ins> An HTTP response with a 2xx status code (RFC7231 Section 6.3) indicates a valid DNS response to the query made in the HTTP request. A valid DNS response includes both success and failure responses. </ins> Different response media types will provide more or less information from a DNS response.  For example, one response type might include the information from the DNS header bytes while another might omit
Original text:
untrusted party.  Instead, a client MUST only trust DNS API server that is configured as trustworthy.  9. Local policy considerations and similar factors mean different DNS

Reviewer comments:
If you're ok with the language I think this is ready to go into the draft based on list discussion. (this does imply to has consensus - everything needs consensus, but as a process matter we need to try and channel those discussions into text for consideration.. its open to feedback, of course)
forked off from which deals with error handling, text on what happens if you choose to handle errors in a non doh fashion related to mailing list thread: A question on the mix of DNS and HTTP semantics

Revised text:
untrusted party.  Instead, a client MUST only trust DNS API server that is configured as trustworthy. <ins> A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy expected by the user of the client. </ins> 9. Local policy considerations and similar factors mean different DNS
Original text:
Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with <del> DNS queries.  Sections 10.6 (Compression) and 10.7 (Padding) of RFC7540 provide some further advice on mitigations within an HTTP/2 context. </del>  The HTTPS connection provides transport security for the interaction between the DNS API server and client, but does not inherently ensure

Reviewer comments:
In section 9 of DOH, it makes the following references: This isn't one of the formats that the tools process will convert into deep links. Instead, the "10.6" becomes a link to section 10.6 of DOH (which doesn't exist), while 10.7 doesn't become a link at all.
thanks. ugh.
HTTP/2 provides further advice about the use of compression (see Section 10.6 of [RFC7540]) and padding (Section 10.7 of [RFC7540]). That removes the "mitigations" word.
Fixed in PR

Revised text:
Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with  <ins> DNS queries.  HTTP/2 provides further advice about the use of compression (Section 10.6 of RFC7540) and padding (Section 10.7 of RFC7540). </ins> The HTTPS connection provides transport security for the interaction between the DNS API server and client, but does not inherently ensure
Original text:
An HTTP response with a 2xx status code (RFC7231 Section 6.3) indicates a valid DNS response to the query made in the HTTP request. A valid DNS response includes both success and failure responses.  Different response media types will provide more or less information from a DNS response.  For example, one response type might include

Reviewer comments:
intended
largely a restating of mailing list thread: A question on the mix of DNS and HTTP semantics
keep pr but reopen the issue to add a little more text
PRs during meetings iz hArd

Revised text:
An HTTP response with a 2xx status code (RFC7231 Section 6.3) indicates a valid DNS response to the query made in the HTTP request. A valid DNS response includes both success and failure responses. <ins> For example, a DNS failure response such as SERVFAIL or NXDOMAIN will contain a successful HTTP 2xx status code even though there was a failure at the DNS layer.  Responses with non-successful HTTP status codes do not contain DNS answers to the question in the corresponding request.  Some of these non-successful HTTPS responses (such as redirects or authentication failures) could allow clients to make new requests to satisfy the original question. </ins> Different response media types will provide more or less information from a DNS response.  For example, one response type might include
Original text:
DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS <del> resolver. </del>  caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect

Reviewer comments:
…dnssec
on list andrew s writes: Section 6 of -03 says this: Different response media types will provide more or less information from a DNS response. For example, one response type might include the information from the DNS header bytes while another might omit it. But section 9 says A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS resolver. It seems to me that these are in tension with one another, because the AD and CD bits are in the header that the response type is permitted to throw away. Maybe it could be resolved thus: NEW A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS resolver. This capability might be affected by the response media type a DNS API server supports.

Revised text:
DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS  <ins> resolver.  This capability might be affected by the response media type. </ins> caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect
Original text:
4.1. <del> The media type is "application/dns-udpwireformat". </del> The data payload is the DNS on-the-wire format defined in RFC1035.  When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query DNS API clients using the DNS wire format MAY have one or more EDNS extensions RFC6891 in the request.  4.2. These examples use HTTP/2 style formatting from RFC7540.

Reviewer comments:
Make clear here that it doesn't intrinsically come with a content-length limit, despite traditional DNS message length limits?
I merged this in a race condition with NAME 's comments. I support that change, but its a little different than the bug that drove this. NAME can you just make the change directly and minimally in this same text?
it could use a preview to help the reader orient herself
See

Revised text:
4.1.  The data payload is the DNS on-the-wire format defined in RFC1035. <ins> The format is for DNS over UDP.  (Note that this is different than the wire format used in RFC7858. </ins> When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query DNS API clients using the DNS wire format MAY have one or more EDNS extensions RFC6891 in the request. <ins> The media type is "application/dns-udpwireformat". </ins> 4.2. These examples use HTTP/2 style formatting from RFC7540.
Original text:
in split DNS configurations RFC6950.  It logically follows that the server which is queried can influence the end result.  Therefore a client's choice of DNS server may affect the responses it gets to its <del> queries. </del>  The HTTPS channel used by this specification establishes secure two party communication between the DNS API Client and the DNS API

Reviewer comments:
wrt mailing list thread DNS64 and DOH andrew sullivan suggests modifying an existing paragraph in operational considerations to have one new sentence: servers may provide different results to the same query: for instance in split DNS configurations [RFC6950]. It logically follows that the server which is queried can influence the end result. Therefore a client's choice of DNS server may affect the responses it gets to its queries. In the case of DNS64 [RFC6147], the choice could affect whether IPv6/IPv4 translation will work at all. in my opinion that's fine. We don't need to enumerate everything, but DNS64 was already called out as a non goal so we might as well note this implication of that.
PR

Revised text:
in split DNS configurations RFC6950.  It logically follows that the server which is queried can influence the end result.  Therefore a client's choice of DNS server may affect the responses it gets to its  <ins> queries.  For example, in the case of DNS64 RFC6147, the choice could affect whether IPv6/IPv4 translation will work at all. </ins> The HTTPS channel used by this specification establishes secure two party communication between the DNS API Client and the DNS API
Original text:
5.5. <del> No updates to Section 5.5 of RFC5216. </del>  5.6.

Reviewer comments:
Bernard has provided links to academic paper describing attacks on availability and ask for updates to the draft describing this. The new paragraph do just that. Added that most things can be spoofed was requested by several persons including Security AD Ben and several TLS people. This was misunderstandings. This is related to the pull request "EAP state machine"
This should address issue
protected failure indicatioin gives the peer an authenticated way to know that the real server sent the failure. It does little or nothing to improve availability as basically any forged message makes TLS fall hard and fatal.
I don't think there is a way to protect the exchange from injection of errors without doing something more extreme like moving to DTLS. It's also not clear that even if the method protected against it that many of the lower layers might have equivalent problems.
"I don't think there is a way to protect the exchange from injection of errors" I don't think so either and think that is fine. I think the important availability goal is that the client and server can try again. I.e. an attacker needs to constantly be active to drop the handshake. I brought this up as Bernard stated that protected failure was important to improve availability. My conclusion is that protected failure does not improve availability as there are other easier was to drop the connection.
I agree with John's analysis. I think this can be closed.
Looks good to me. We may need to edit to add protected success indications.

Revised text:
5.5.  <ins> As decscribed in RFC3748 and Section 5.5 of RFC5216, the only information that is integrity and replay protected in EAP-TLS are the parts of the TLS Data that TLS protects.  All other information in the EAP-TLS message exchange including EAP-Request and EAP-Response headers, the identity in the identity response, EAP-TLS packet header fields, Type, and Flags, EAP-Success, and EAP-Failure can be modified, spoofed, or replayed.  This section updates Section 5.5 of RFC5216. Protected TLS Error alerts are protected failure result indications and enables the EAP-TLS peer and EAP-TLS server to determine that the failure result was not spoofed by an attacker.  Protected failure result indications provide integrity protection and replay but MAY be unauthenticated.  Protected failure result does not significantly improve availability as TLS 1.3 treats most malformed data as a fatal error. </ins> 5.6.
Original text:
1.3 the key schedule is described in Section 7.1 of RFC8446. When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, <del> IV, and Method-Id SHALL be derived from the exporter_master_secret using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). </del>  A zero-length context (indicated by "") is used in the TLS exporter interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is above keying material. By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation <del> without having to extract the Master Secret, ClientHello.random, and </del>  ServerHello.random in a non-standard way. 2.4.

Reviewer comments:
TLS WG has decided to change terminology in TLS 1.2 and TLS 1.3. The draft is already WG adopted. I suggest we make this change in EAP-TLS 1.3 as well.
Looks good to me

Revised text:
1.3 the key schedule is described in Section 7.1 of RFC8446. When EAP-TLS is used with TLS version 1.3 or higher the Key_Material,  <ins> IV, and Method-Id SHALL be derived from the exporter_secret using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). </ins> A zero-length context (indicated by "") is used in the TLS exporter interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is above keying material. By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation  <ins> without having to extract the Main Secret, ClientHello.random, and </ins> ServerHello.random in a non-standard way. 2.4.
Original text:
TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). <del> A zero-length context (indicated by "") is used in the TLS exporter interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is appended to the label strings.  Other TLS based EAP methods can use exporters in a similar fashion by replacing the EAP-TLS Type-Code with their own Type-Code (encoded as a hexadecimal string). </del>  RFC5247 deprecates the use of IV.  Thus, RECV-IV and SEND-IV are not exported in EAP-TLS with TLS 1.3.  As noted in RFC5247, lower layers

Reviewer comments:
Appending things to labels are not agreeing with the IANA registry for labels. Registering labels for each TLS based EAP type would explode the registry.
For the historic record, could you also record where this feedback originated from?
This was discussed during EMU WG IETF 110 and the WG consensus was to go back to using context. URL For the reasons metioned in the first comment, this seemed like the best solution. This is also what has been interoptested (but implementors stated they they could change if needed.) URL The consunsus during the meeting was. Change back to using context If 1. is not approved by IESG, then registed a larger number of labels with the type code in the label.
I think we still need to come to consensus on where the EAP-Type goes Label Context If the consensus is label then we need to determine how to incorporate IANA considerations as either a fixed string or reserve a prefix string
I thought we had consensus during IETF 110 to use type-code in the context. I had closed and merged PR
OK good, I hadn't seen the issue close and didn't realize there was a PR associated with it. Closing this as resolved by PR

Revised text:
TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446).  <ins> Other TLS based EAP methods can use exporters in a similar fashion by replacing the EAP-TLS Type-Code with their own Type-Code (encoded as a hexadecimal string). </ins> RFC5247 deprecates the use of IV.  Thus, RECV-IV and SEND-IV are not exported in EAP-TLS with TLS 1.3.  As noted in RFC5247, lower layers
Original text:
EAP-TLS, see Section 4.2.10 of RFC8446 for additional information of the "early_data" extension.  Resumption is handled as described in resumption.  TLS 1.3 introduced the Post-Handshake KeyUpdate message <del> which is not useful and not expected in EAP-TLS.  The EAP-TLS server always commits to not send any more handshake messages by sending a TLS close_notify alert.  After the EAP-TLS server has received an empty EAP-Response to the EAP-Request containing the TLS close_notify alert, the EAP-TLS server sends EAP-Success. </del>  figbase1 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest

Reviewer comments:
This was discussed and EMU WG IETF 110. URL URL Interop test was done by several implementors during the hackaton. The conclusions was the application data works well as a protected success indication and that close_notify is problematic. Alan DeKok stated that application data will not cause problems for other TLS based EAP methods. The consensus in the WG was to use application data 0x00 as a protected success indication on the EAP-TLS layer. The application data is not controlling the TLS layer. After sending application data (or any other success indication) the EAP-TLS can only send EAP-SUCCESS. The working group argued that the IESG and TLS WG resistance against use application data was as it was used in -13 when it promised that no more handshake messages was sent by the TLS layers. The EMU WG hopes and thinks that the IESG and the TLS WG will be ok with the current use of applicaiton data as a protected success indication on the EAP-TLS layer. Additional changes related to this (protected success and protected failure) will/is done in the EAP State Machnine PR.
There seems to be consensus to use the 0x00 application data as a result indicator for EAP-TLS. See PR
Closing as PR is merged

Revised text:
EAP-TLS, see Section 4.2.10 of RFC8446 for additional information of the "early_data" extension.  Resumption is handled as described in resumption.  TLS 1.3 introduced the Post-Handshake KeyUpdate message  <ins> which is not useful and not expected in EAP-TLS.  As a protected success indication RFC3748 the EAP-TLS server always sends TLS application data 0x00, see Section 2.5.  Note that a TLS implementation MAY not allow the EAP-TLS layer to control in which order things are sent and the application data MAY therefore be sent before a NewSessionTicket.  TLS application data 0x00 is therefore to be interpretated as success after the EAP-Request that contains TLS application data 0x00.  After the EAP-TLS server has received an empty EAP-Response to the EAP-Request containing the TLS application data 0x00, the EAP-TLS server sends EAP-Success. </ins> figbase1 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest
Original text:
section is relevant for EAP-TLS in general (regardless of the underlying TLS version used).  EAP-TLS is typically encapsulated in other protocols, such as PPP RFC1661, RADIUS RFC2865, Diameter RFC6733, or PANA RFC5191.  The encapsulating protocols can also provide additional, non-EAP

Reviewer comments:
Discuss security implementations of no peer authentication in the authorization section of section 5. This addresses issue
NAME does this PR address this issue?
Yes, thanks.
Section 5 should have text discussing the security aspects of "no peer authentication" Perhaps: MUST put users into a limited access network MUST NOT allow resumption Otherwise the unauthenticated users would get open access to secure networks.

Revised text:
section is relevant for EAP-TLS in general (regardless of the underlying TLS version used). <ins> EAP servers will usually require the EAP peer to provide a valid certificate and will fail the connection if one is not provided. Some deployments may permit no peer authentication for some or all connections.  When peer authentication is not used, implementations MUST take care to limit network access appropriately for unauthenticated peers and implementations MUST use resumption with caution to ensure that a resumed session is not granted more privilege than was intended for the original session. </ins> EAP-TLS is typically encapsulated in other protocols, such as PPP RFC1661, RADIUS RFC2865, Diameter RFC6733, or PANA RFC5191.  The encapsulating protocols can also provide additional, non-EAP
Original text:
received the client Finished message in the initial authentication. The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The <del> NewSessionTicket message MUST NOT include an "early_data" extension. Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario.  In most cases a single newSessionTicket will be sufficient.  A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I- D.ietf-tls-ticketrequests. </del>  figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a

Reviewer comments:
Added text to make sure the client cert is validated before a NST is sent and stated that early data must be ignored: This is to address issue .
NAME does this PR address the issue?
yes, thanks.
From Alan's review: >

Revised text:
received the client Finished message in the initial authentication. The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The  <ins> NesSessionTicket MUST NOT be sent before the client's certificate has been validated.  The NewSessionTicket message MUST NOT include an "early_data" extension.  If the "early_data" extension is received then it MUST be ignored.  Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario.  In most cases a single newSessionTicket will be sufficient.  A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I-D.ietf-tls-ticketrequests. </ins> figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a