jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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
Change:
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

Discussion:
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
Change:
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

Discussion:
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> <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
Change:
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

Discussion:
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
Change:
…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.

Discussion:
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> <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
Change:
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

Discussion:
4.1. <del> The media type is "application/dns-udpwireformat". </del> 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.
Change:
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

Discussion:
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> <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
Change:
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.

Discussion:
5.5. <del> No updates to Section 5.5 of RFC5216. </del> <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.
Change:
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

Discussion:
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> <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 <del> without having to extract the Master Secret, ClientHello.random, and </del> <ins> without having to extract the Main Secret, ClientHello.random, and </ins> ServerHello.random in a non-standard way. 2.4.
Change:
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

Discussion:
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> <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
Change:
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

Discussion:
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> <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
Change:
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.

Discussion:
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
Change:
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: >

Discussion:
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> <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
Change:
I see that "EAP-TLS 1.3" is used more an more in the discussions to refer to this the combination of EAP-TLS and TLS 1.3. The term is used in the document but not in the title and abstract
Hi John, Please run this title change by the list.
Looking at this it seems that this change is simpler than I originally thought. This looks OK to merge

Discussion:
<del> Using EAP-TLS with TLS 1.3 </del> <ins> Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) </ins> draft-ietf-emu-eap-tls13-latest Abstract

Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS.  TLS 1.3 provides significantly improved security, privacy, and reduced latency when <del> compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking.  This document also provides guidance on </del> <ins> compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking.  This document also provides guidance on </ins> authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  This document updates RFC 5216.
Change:
While reading draft-ietf-emu-eap-tls13-15 I noticed that section now uses which is the named used in but not in RFC 8446 itself. I first thought this was a typo, before a further look showed that this change was mentioned in IETF 110 . Suggestion: make clear which parts need to be looked up from RFC 8446bis. In addition to exporter terminology, the meeting slides above also discuss about usercancelled behavior on slide 10. For clarity, any updates from RFC 8446bis should be marked clearly.
It would be best not to have normative references that block on RFC 8446bis. Perhaps we can just reference that it is renamed from "exportermastersecret"
Sounds good. That should make clear where it comes from and that there's no need to file errata about unknown term and/or RFC 8446bis dependency. Taking another look at my comment about usercancelled behavior on slide 10; to clarify what I was meaning: The slides hint that clarifications in 8446bis are needed by EAP-TLS too. If so, this looks like a reference to RFC 8446bis too. Finally, one nit: the alert name in RFC 8446 is "usercanceled", not "user_cancelled" as in draft -15.
I made a PR with explaining that the document use the terminology from RFC8446bis. URL Do we need to say anything about usercancelled? RFC8446bis might do several clarifications and corrections. I think we should only mention things that are directly relevant for EAP-TLS 1.3 URL Current plan for RFC8446bis seems to be to ignore closenotify and I assume require close_notify after. This does not seem directly relevant for EAP-TLS 1.3. Or?
close issue?
Yes, please close this. I think it's now clear where exportersecret comes from. Also, thanks for the pointer to TLSv1.3 discussion. I agree usercanceled followed by close_notify discussion is not relevant for EAP-TLS 1.3. It's seems to be TLSv1.3 specification and implementation level detail as opposed to something that EAP-TLS 1.3 needs to directly react on.

Discussion:
stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. <ins> This document follows the terminology from I-D.ietf-tls-rfc8446bis where the master secret is renamed to the main secret and the exporter_master_secret is renamed to the exporter_secret. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

for the entity acting as EAP peer and TLS client.  The term EAP-TLS server is used for the entity acting as EAP server and TLS server. <ins> Readers are expected to be familiar with the terms and concepts used in EAP-TLS RFC5216 and TLS RFC8446.  The term EAP-TLS peer is used for the entity acting as EAP peer and TLS client.  The term EAP-TLS server is used for the entity acting as EAP server and TLS server. </ins> 2. 2.1.