jiebi/CodeConvo huggingface dataset:
Code change:
added authenticity
The potential for misunderstanding here is great. If we consider authenticity to be stated as a goal, we would need more explicit about the properties that this provides. Specifically, this does not provide authenticity with respect to responses, because that is the purpose of DNSSEC.
Yes, that is true. Thinking about it, I think a web application developer (one of the targets) reading this draft might not fully understand the differences between authenticity at the HTTP layer and authenticity at the DNS layer. One of the stated features of Secure Contexts is authenticated channels that guarantee data integrity. If possible, I think a few more sentences elaborating on this topic would not hurt.
I'm going to close this because we have no idea what kind of authentication that a user would expect, whereas we know pretty well what kind of privacy they expect.
I think there might be room for something different along these lines. DNS hijack from your configured DNS server is currently a major problem, and DoH does allow you to authenticate whether or not you are talking to your configured recursive (while not saying anything about e2e). I'm going to reopen to track..

Related discussion:
text: 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 <del> DNS retrieval mechanism, doing so can weaken the privacy expected by the user of the client. </del> <ins> DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client. </ins> 9.
Code change:
Hello, I am a non-native English speaker but I noticed the following sentence: "Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very poor performance for many uses cases." Shouldn't be there at the end? Wiktionary ( URL ) suggests that plural of "use case" is "use cases", not "uses cases".

Related discussion:
text: to achieve similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very <del> poor performance for many uses cases. </del> <ins> poor performance. </ins> 6.3.
Code change:
Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.

Related discussion:
text: The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client <del> MUST be prepared to process "message/dns" (as described in dnswire) responses but MAY also process any other type it receives. </del> <ins> MUST be prepared to process "application/dns-message" (as described in dnswire) responses but MAY also process any other type it receives. </ins> In order to maximize cache friendliness, DNS API clients using media <del> formats that include DNS ID, such as message/dns, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as message/ dns.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </del> <ins> formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-message.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </ins> DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.
Code change:
Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.

Related discussion:
text: "https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records. <del> The requests are represented as message/dns typed bodies. </del> <ins> The requests are represented as application/dns-message typed bodies. </ins> The first example request uses GET to request www.example.com
Code change:
Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.

Related discussion:
text: At the time this is published, the response types are works in progress.  The only response type defined in this document is <del> "message/dns", but it is possible that other response formats will be defined in the future. </del> <ins> "application/dns-message", but it is possible that other response formats will be defined in the future. </ins> <del> The DNS response for "message/dns" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </del> <ins> The DNS response for "application/dns-message" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP exchange.  The responses may be processed and transported in any order using HTTP's
Code change:
Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.

Related discussion:
text: caching discusses the relationship between DNS and HTTP response caching. <del> A DNS API server MUST be able to process message/dns request messages. </del> <ins> A DNS API server MUST be able to process application/dns-message request messages. </ins> A DNS API server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to
Code change:
Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.

Related discussion:
text: 5.4. In order to maximize interoperability, DNS API clients and DNS API <del> servers MUST support the "message/dns" media type.  Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </del> <ins> servers MUST support the "application/dns-message" media type.  Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </ins> 6.
Code change:
Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.

Related discussion:
text: DNS API clients using the DNS wire format MAY have one or more EDNS options RFC6891 in the request. <del> The media type is "message/dns". </del> <ins> The media type is "application/dns-message". </ins> 7.
Code change:
The "using https:// URIs" part is just odd. Easier to simply state that this uses HTTPS at this level. Also, if the concept of a DNS service evolves to encompass other types of exchange than simple request-response, then "run DNS service" won't be accurate.
I added "DOH" to the title because it was now being removed from the Abstract.

Related discussion:
text: <del> DNS Queries over HTTPS </del> <ins> DNS Queries over HTTPS (DOH) </ins> draft-ietf-doh-dns-over-https Abstract <del> This document describes how to run DNS service over HTTP (DOH) using https:// URIs. </del> <ins> This document describes how to make DNS queries over HTTPS. </ins> 1. This document defines a specific protocol for sending DNS RFC1035 <del> queries and getting DNS responses over HTTP RFC7540 using https:// </del> <ins> queries and getting DNS responses over HTTP RFC7540 using https URIs </ins> (and therefore TLS RFC5246 security for integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP exchange.
Code change:
This is OK, but I like the changes in better because it brings the "trust" discussion further forwards. Preferences?
I prefer this PR over - changing from trust to authorization is more on point
I agree authorize is closer to the correct concept here but I'd like to see a definition of it (in a section of it's own early in the document). But - I don't believe there is an existing concept in DNS or DNSSEC that this is re-using? Does 'authorize' here mean that: the client will use all response from that server for resolution the client will cache all responses received from that server Also, if the trusted resolver itself isn't doing DNSSEC validation then the client's cache can still be poisoned. The only 100% sure method to stop cache poisoning is for the caching entity to perform DNSSEC validation.

Related discussion:
text: 5.3. Before using DOH response data for DNS resolution, the client MUST <del> establish that the HTTP request URI is a trusted service for the DOH query.  For HTTP requests initiated by the DNS API client this trust </del> <ins> establish that the HTTP request URI is authorized for the DOH query. For HTTP requests initiated by the DNS API client this authorization </ins> is implicit in the selection of URI.  For HTTP server push (RFC7540 Section 8.2) extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request.  This specification does not extend DNS resolution privileges to URIs that are not recognized by the <del> client as trusted DNS API servers. </del> <ins> client as authorized DNS API servers. </ins> 5.4.
Code change:
This is OK, but I like the changes in better because it brings the "trust" discussion further forwards. Preferences?
I prefer this PR over - changing from trust to authorization is more on point
I agree authorize is closer to the correct concept here but I'd like to see a definition of it (in a section of it's own early in the document). But - I don't believe there is an existing concept in DNS or DNSSEC that this is re-using? Does 'authorize' here mean that: the client will use all response from that server for resolution the client will cache all responses received from that server Also, if the trusted resolver itself isn't doing DNSSEC validation then the client's cache can still be poisoned. The only 100% sure method to stop cache poisoning is for the caching entity to perform DNSSEC validation.

Related discussion:
text: security implications of HTTP caching for other protocols that use HTTP. <del> A server that is acting both as a normal web server and a DNS API server is in a position to choose which DNS names it forces a client to resolve (through its web service) and also be the one to answer those queries (through its DNS API service).  An untrusted DNS API server can thus easily cause damage by poisoning a client's cache with names that the DNS API server chooses to poison.  A client MUST NOT trust a DNS API server simply because it was discovered, or because the client was told to trust the DNS API server by an untrusted party.  Instead, a client MUST only trust DNS API server that is configured as trustworthy. </del> <ins> In the absence of information about the authenticity of responses, such as DNSSEC, a DNS API server can poison a client's cache.  A client MUST NOT authorize arbitrary DNS API servers.  Instead, a client MUST specifically authorize DNS API servers using mechanisms such as explicit configuration. </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
Code change:
NAME I'm ok with you merging this and closing 11 if you're ok with it.
I think that it is fine - or more precisely, invaluable - to explain what the semantics of server push are. But you don't actually require HTTP/2 for this protocol to work. The only thing that requiring HTTP/2 gets you is tighter constraints on TLS usage. You can get those same constraints with some deployment recommendations. I would support strong recommendations that said HTTP/2 is useful for its multiplexing as well as similarly strong advice about following the advice in RFC 7525. Those are both good practice.
fairly clear feedback from singapore to change this to an endorsement (SHOULD) with better explanatory text focusing on performance and scale.
What are the drawbacks of HTTP/2? Less readily available libraries? more complex protocol? Potential difficulties in integrating with current fronting stacks that may not be HTTP/2 ready? On one hand, I feel like it may be easier to just enforce 1 stack for now rather than having to support multiple flavor of client/server protocols. A suboptimal HTTP/2 implementation may just be similar to HTTP/1 but at least we can try to move forward toward multiplexing. Making HTTP/2 a should may just leave us in limbo in HTTP/1 land.
NAME the singapore meeting is available here URL .. goto the 12 minute mark to review the discussion (wrt your question about drawbacks).
Text is in URL
Last PR accepted. I suspect there will be a bit more wordsmithing, but this should cover the main issue well.
thanks, I was in the room, but my notes were sparse and some of the cons I remembered of were more inconvenience to me than blockers. What I am not getting from the current spec, and which I believe NAME touched on in URL, is that it is unclear whether or not a minimum HTTP version must be supported. Based on URL , do we consider that by supporting HTTP/1.1 we get HTTP/1.0 for free and consider 0.9 not an option? Wouldn't not mandating a required version prevent client/server from having a known version to use? Can we make this clearer maybe?
The decision was to rely only on HTTP semantics and not versions. So any HTTP implementation that is acceptable to its peer can be used.

Related discussion:
text: partially because they did not follow HTTP best practices. This document defines a specific protocol for sending DNS RFC1035 <del> queries and getting DNS responses over modern versions of HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP request-response pair. </del> <ins> queries and getting DNS responses over HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP request-response pair. </ins> The described approach is more than a tunnel over HTTP.  It establishes default media formatting types for requests and responses
Code change:
NAME I'm ok with you merging this and closing 11 if you're ok with it.
I think that it is fine - or more precisely, invaluable - to explain what the semantics of server push are. But you don't actually require HTTP/2 for this protocol to work. The only thing that requiring HTTP/2 gets you is tighter constraints on TLS usage. You can get those same constraints with some deployment recommendations. I would support strong recommendations that said HTTP/2 is useful for its multiplexing as well as similarly strong advice about following the advice in RFC 7525. Those are both good practice.
fairly clear feedback from singapore to change this to an endorsement (SHOULD) with better explanatory text focusing on performance and scale.
What are the drawbacks of HTTP/2? Less readily available libraries? more complex protocol? Potential difficulties in integrating with current fronting stacks that may not be HTTP/2 ready? On one hand, I feel like it may be easier to just enforce 1 stack for now rather than having to support multiple flavor of client/server protocols. A suboptimal HTTP/2 implementation may just be similar to HTTP/1 but at least we can try to move forward toward multiplexing. Making HTTP/2 a should may just leave us in limbo in HTTP/1 land.
NAME the singapore meeting is available here URL .. goto the 12 minute mark to review the discussion (wrt your question about drawbacks).
Text is in URL
Last PR accepted. I suspect there will be a bit more wordsmithing, but this should cover the main issue well.
thanks, I was in the room, but my notes were sparse and some of the cons I remembered of were more inconvenience to me than blockers. What I am not getting from the current spec, and which I believe NAME touched on in URL, is that it is unclear whether or not a minimum HTTP version must be supported. Based on URL , do we consider that by supporting HTTP/1.1 we get HTTP/1.0 for free and consider 0.9 not an option? Wouldn't not mandating a required version prevent client/server from having a known version to use? Can we make this clearer maybe?
The decision was to rely only on HTTP semantics and not versions. So any HTTP implementation that is acceptable to its peer can be used.

Related discussion:
text: 9. Running DNS over HTTPS relies on the security of the underlying HTTP <del> connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure transport. </del> <ins> transport.  Implementations utilizing HTTP/2 benefit from the TLS profile defined in RFC7540 Section 9.2. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with
Code change:
I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Related discussion:
text: but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are expected to make this protocol function in some environments where <del> DNS directly on TLS (RFC7858) would not. </del> <ins> unsecured DNS (DNS) or DNS directly on TLS (RFC7858) would not. </ins> A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done
Code change:
Proposal to change the derivation of the EMSK and MSK individually and directly from TLS exporter. Defines new tags for this purpose.
Thanks!

Related discussion:
text: using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). <del> All other parameters such as MSK and EMSK are derived in the same manner as with EAP-TLS RFC5216, Section 2.3.  The definitions are repeated below for simplicity: </del> <ins> All other parameters are derived in the same manner as with EAP-TLS RFC5216, Section 2.3.  The definitions are repeated below for simplicity: </ins> The use of these keys is specific to the lower layer, as described RFC5247.
Code change:
URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".

Related discussion:
text: order things are sent and the application data MAY therefore be sent before a NewSessionTicket.  TLS application data 0x00 is therefore to be interpreted as success after the EAP-Request that contains TLS <del> 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. </del> <ins> application data 0x00.  After the EAP-TLS server has sent an EAP- Request containing the TLS application data 0x00 and received an EAP- Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server sends EAP-Success. </ins> figbase1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest
Code change:
URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".

Related discussion:
text: "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode is also important in order to limit the impact of a key compromise. When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning <del> that key leakage does not compromise any earlier connections.  It is RECOMMMENDED to use "psk_dhe_ke" for resumption. </del> <ins> that key leakage does not compromise any earlier connections.  The "psk_dh_ke" mechanism MUST be used for resumption unless the deployment has a local requirement to allow configuration of other mechanisms. </ins> 2.1.4.
Code change:
URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".

Related discussion:
text: figterm3 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer <del> fails to authenticate to the EAP-TLS server and sends a TLS Error alert. </del> <ins> fails to authenticate to the EAP-TLS server and the server sends a TLS Error alert. </ins> 2.1.5.
Code change:
URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".

Related discussion:
text: accounting. As suggested in RFC8446, EAP-TLS peers MUST NOT store resumption PSKs <del> or tickets (and associated cached data) for longer than 7 days, regardless of the PSK or ticket lifetime.  The EAP-TLS peer MAY delete them earlier based on local policy.  The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired.  In all such cases, an attempt at resumption results in a full TLS handshake instead. </del> <ins> or tickets (and associated cached data) for longer than 604800 seconds (7 days), regardless of the PSK or ticket lifetime.  The EAP- TLS peer MAY delete them earlier based on local policy.  The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired. In all such cases, an attempt at resumption results in a full TLS handshake instead. </ins> Information from the EAP-TLS exchange (e.g., the identity provided in EAP-Response/Identity) as well as non-EAP information (e.g., IP