Since clients can receive DNS SVCB answers over unencrypted DNS, on- path attackers can prevent successful discovery by dropping SVCB <del> queries or answers.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. </del>  DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the

I think that the answer here is that DDR resolution is SVCB-reliant as defined in the SVCB spec. Can you make that explicit please?
says It sounds like you're saying that DDR should adopt this without adjustments. That seems reasonable to me.
Right. I sort of assumed that it was SVCB-reliant, but it doesn't say that. Certainly, this is not a case where any deviation from spec is necessary. (The more of those we have, the better.)
DDR predates when the reliant and optional terms came about, which is why it wasn’t covered. I’m not clear on why anything would need to be said here. Reliant and optional seem to be modes for the client to block on getting SVCB records or falling back and ignoring them if they don’t arrive. Discovery based on IP addresses is done with an SVCB query for URL, and no other query types are allowed for URL By definition, this only works with SVCB. That doesn’t mean that a client can’t be SVCB optional for its general operation — it just means that if SVCB is blocked or fails, you don’t get to discover the encrypted resolver. What do we need to say here that would actually benefit things?
So SVCB-optional doesn't even make sense for this specification. I was just looking for a nudge in the form of: "The resolver/client uses SVCB in a SVCB-reliant mode." Just so that there is no confusion.
Yes, optional doesn’t make sense. But I still think that the entire reliant/optional choice is orthogonal to how DDR works. These are the two lines that mention reliant mode in the SVCB spec: Both of these seem to be about client behavior for connection establishment to a hostname. It’s specifically about connecting. It doesn’t make sense to connect to URL; this is a special purpose SVCB query used for discovery, which can lead to a connection. I don’t see any requirement from the SVCB spec that protocols that use SVCB need to define themselves as “reliant” or “optional”. Is there something I’m missing there?
How is this not about connecting from the point at which you feed the name into a SVCB query? A DDR client is trying to connect to a (secure) resolver. To that end, it is making a SVCB query. That it uses "URL" doesn't change the overall goal.
Until a client uses the SVCB query for discovery, it doesn’t know if an encrypted resolver exists that is designated. I’m not sure if saying a DDR-aware client is “SVCB-reliant” means that it will not use the unencrypted resolver for application queries until it discovers an encrypted resolver (which is not a requirement, obviously, since clients can be allowed to continue using unencrypted DNS if their local policy allows it), or it means that the connection to the discovered encrypted DNS server is SVCB-reliant, which is tautologically true since the existence of said server was only discovered via SVCB. If it’s the former, we shouldn’t say it because it’s really about client policy for allowing unencrypted DNS. If it’s the latter, I don’t see the value of adding anything, and I’m not sure it really fits the meaning of “reliant”.
I believe DDR clients' recommended behavior is exactly the behavior recommended in Section 8.2 of SVCB-DNS, quoted above. It is initially SVCB-optional, and becomes SVCB-reliant once SVCB resolution succeeds. Specifically: if you do discover an encrypted resolver, and you attempt connection, you SHOULD NOT fall back to unencrypted if that connection fails. Otherwise, you've added a downgrade vulnerability to attackers on the "transport path" (which may not be the same as the bootstrap-query path). As this is the default recommendation for SVCB-DNS, I don't think any additional normative language is strictly required. However, I think a reminder might be appropriate. This does not address the question of whether to wait for SVCB resolution before issuing any initial queries. As a practical matter, I don't think we can require that.
Okay, I agree with the behavior you describe there of being initially optional and then becoming reliant. I can try to find a place where it makes sense to reference that section.

Since clients can receive DNS SVCB answers over unencrypted DNS, on- path attackers can prevent successful discovery by dropping SVCB  <ins> queries or answers, and thus prevent clients from switching to use encrypted DNS.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the


I have committed all request changes. Thank you for the refinements.
The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, IANA understands that this document calls for the addition of "URL" to the Special-Use Domain Names (SUDN) registry established by RFC6761. RFC6761 specifically requires that any request for a Special-Use Domain Name needs to contain a subsection of the "IANA Considerations" section titled Domain Name Reservation Considerations. The current draft does not have such a section. IANA Question --> Could the authors either conform to the requirements of RFC6761 or provide explicit guidance as to why that section is not appropriate? Second, in the Transport-Independent Locally-Served DNS Zone Registry on the Locally-Served DNS Zones registry page located at: URL a new registration will be made as follows: Zone: URL Description: DNS Resolver Special-Use Domain Reference: [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: URL

Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document as the reference. <ins> 8.2. In accordance with Section 5 of RFC6761, the answers to the following questions are provided relative to this document: Are human users expected to recognize these names as special and use them differently?  In what way? No.  This name is used automatically by DNS stub resolvers running on client devices on behalf of users, and users will never see this name directly. Are writers of application software expected to make their software recognize these names as special and treat them differently?  In what way? No.  There is no use case where a non-DNS application (covered by the next question) would need to use this name. Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently?  If so, how? Yes. DNS client implementors are expected to use this name when querying for a resolver's properties instead of records for the name itself.  DNS servers are expected to respond to queries for this name with their own properties instead of checking the matching zone as it would for normal domain names. Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? Yes. Caching domain name servers should not forward queries for this name to avoid causing validation failures due to IP address mismatch. Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? No.  DDR is designed for use by recursive resolvers.  Theoretically, an authoritative server could choose to support this name if it wants to advertise support for encrypted DNS protocols over plain-text DNS, but that scenario is covered by other work in the IETF DNSOP working group. Does this reserved Special-Use Domain Name have any potential impact on DNS server operators?  If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid?  Do DNS server operators need to know about that and understand why?  Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware? This name is locally served, and any resolver which supports this name should never forward the query.  DNS server operators should be aware that records for this name will be used by clients to modify the way they connect to their resolvers. How should DNS Registries/Registrars treat requests to register this reserved domain name?  Should such requests be denied? Should such requests be allowed, but only to a specially- designated entity? IANA should hold the registration for this name.  Non-IANA requests to register this name should always be denied by DNS Registries/ Registrars. </ins>


should be able to use those records while safely ignoring the third record. <del> To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of RFC8484 regarding the avoidance of DNS- based references that block the completion of the TLS handshake. </del>  This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-

DISCUSS: CC NAME See my discuss on draft-ietf-add-ddr-11 for my generic ADD DNR/DDR concerns Resolver without some sort of validation Why not? What is the alternative? Using unencrypted DNS to the party that told you how and where to contact these (unvalidated) Designated Resolvers. Resolver that does not use a private or local IP address and can be verified using the mechanism described in Section 4.2, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in Section 4.2. This seems to go against a lot of advise in the documents that networks must be treated independently. Also, the network wants you to use their designated resolver, so to say it is okay to use a totally different Designated Resolvers seems to violate the whole DNR/DDR architecture. This will also cause failure if there is split-DNS or internal-only data. Also, using "public IP" is not a good trustworthy method to prove that these IPs are truly the same Designated Resolver used by both networks. I can easily use an internal only zone with . IN A 8.8.8.8 and get a valid ACME'd certificate with SAN=. The user connecting to another network might now be switching from my private DNS on my stolen 8.8.8.8 IP to the real google DNS. address of the designating Unencrypted Resolver in a subjectAltName extension. How feasible is it to get a certificate with SAN=ip from one of the generally accepted root store CA's? Can you give me one example where I can get a certificate for with SAN=193.110.157.123 ? I do not think this is currently possible or easy. If I am right, that means all of Section 4.2 is wishful thinking and not realistic to get rolled out. (I know we can see the cert for 1.1.1.1, so it is possible, but I know of no ACME supported CA that issues these) discovered Designated Resolver. This creates a strange policy when compared to DNR where if you get a DHCP or RA for the Designated Resolver, which is also not validatable, that you do end up using it? And section 6.5 states DNR trumps DDR. address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check (Section 4.3). Why only when the IP is the same? Why not for when the IP is different? What's to lose, since the only fallback option is stick to using the unencrypted resolver? yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query, the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known and validated IP address for the same Designated Resolver name. How does the appearance of an (unsigned) Additional Answer entry convey any kind of real world trust/authentication? In other words, why should it not ALWAYS pass the same TLS certificate checks ? is to use unencrypted DNS, why not just use it anyway? use DDR to discover details about all supported encrypted DNS protocols. It's a little odd to mention this as the DNR draft really tries hard to say to only use the network's offered encrypted DNS servers, so this option is in conflict with the DNR draft. Unfortunately, all currently deployed software does not know this, so it will be very common that this happens. URL SHOULD treat URL as a locally served zone per [RFC6303] Why is this not a MUST ? queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. I don't see how this would improve security for the client. It also mixes up behaviour of proper DNS clients that have their own retransmit logic for if they get no answer. attack where an attacker can block connections to the encrypted DNS server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed. For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires I wonder which attacker can block encrypted DNS connections but not spoof (or block!) an unsigned SVCB record to the local client? And even if that is the case, this would be a denial of service attack if the DNS client cannot fallback to unencrypted DNS. Spoofing an SVCB to a bogus IP with an SVCB TTL of a few hours would be a very cheap 1 packet attack to keep the DNS client down for hours. This seems dangerous to implement. unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" parameter. For example, if a DoH resolver provides provides a filtering service for one URI path, and a non-filtered service for another URI path, [...] It seems likely that this advise will get ignored a lot, eg by people who have limited public IPs to use to spin up a DoH server, or who have to pay-per-IP. This advise seems more appropriate for local private IP DoH servers. So I would change this MUST NOT to SHOULD NOT for that reason. Unencrypted Resolver, clients applying Verified Discovery (Section 4.2) MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Designated Resolver's TLS certificate. How would one obtain such a certificate via ACME? Since on the IP of the unencrypted resolver, there would be no HTTP server running? Additionally, if the client notices a failed verification of the Designated Resolver's TLS certificate, wouldn't it fallback to the Unencrypted Resolver? But now it may not? So this becomes a denial of service then ? to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. Based on earlier text, this should read "the same non-public IP address". you use "unilateral probing" (draft-ietf-dprive-unilateral-probing) to just connect to the DoT or DoQ ports of the Unencrypted Resolver and see if you get anything back. It might be unauthenticated TLS but better than port 53? Special-Use Domain Names (SUDN) registry established by [RFC6761]. Why not pick URL As .local is already handled to not be forwarded by DNS forwarders. It would also not require an addition to SUDN. Even if someone was already using URL, it would not interfere with that usage because that usage would not be using SVCB records. To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of [RFC8484] regarding the avoidance of DNS- based references that block the completion of the TLS handshake. I find that reference to list more the issues than solutions that can be followed. The solution to use another DoH server is not really appropriate in most cases The client's other interface likely resides on other networks where its private DoH server cannot resolve the name of another network's private DoH server. It is also not easy to get an IP based certificate (eg SAN=ip) that is accepted by general webpki root stores. And things like OCSP stapling doesn't help if the target is malicious - they just would omit the stapling that proves against its malicious use. The only real advise usable from RFC8484 is "use the local unencrypted resolver to resolve the encrypted resolver". Might as well say that and remove the 8484 reference. as the protocol is mentioned throughout the document as interacting with this protocol. when accessing web content on a dual-stack network: A, AAAA, and HTTPS queries. Discovering a Designated Resolver as part of one of these queries, without having to add yet another query, minimizes the total number of queries clients send. I don't understand this paragraph. Once clients can send SVCB queries for web content, they already have had to do all the DDR/DNR related queries, so I don't understand the argument of "saving queries" ? Also, it is adding queries for a specific target, eg URL, and this cannot be "saved" either? What am I misunderstanding here? provides provides -> provides
We should reference Security Considerations, because if you don't have any validation, an attacker can point you to any server they want (someone other than the server you were configured with by DHCP, etc).
We can probably just remove this, not using it in implementations right now.
It's already done by the major public resolvers, and there is an RFC to support this (RFC 8738). The IP address validation is clearly important and a matter of WG consensus. Hopefully, this will push adoption of RFC 8738 by more ACME services.
We can reference the DNR section. The MUST NOT should only apply to DDR, but doesn't invalidate other ways of using the resolver.
If they are different, it can be a random attacker (see security considerations). The client may also have other better options to fall back to.
Agree, this should be simplified to say "even if you connect over a different IP address for any reason, still validate the original IP address"
There are definitely cases where the client can have directly selected their own resolver name, etc. We don't have to use the network resolver.
Correct, and that's why we need this document, and it was added to the IANA section.
Sure, we can make this a MUST.
It makes the attacker's job harder by requiring them to be persistent. Normal retransmission logic is fine too.
This is a direct outcome of the svcb-dns document. Spoofing SVCB shouldn't be enough to cause a DoS here, because we should continue to use the previously used encrypted DNS server while on this network (even if you get a bad SVCB packet).
For the security reasons, I think this needs to stay as a MUST NOT. However, if you differentiate based on hostname + path, you can still differentiate, it just isn't a differentiation that can be discovered by IP address queries.
Yes, you'd fall back to unencrypted resolution if you can't have a secure trusted connection for encrypted resolution.
Yes, but that part is SHOULD. Will fix.
I think that's just opportunistic DoT / DoQ. That's already specified.
.local is the SUDN for multicast DNS, but it is also squatted on by some internal networks. Following the patterns for URL, etc, .arpa is a much more appropriate name. This is what the group had consensus on years ago and has been deployed widely already.
I think we can say "as explained in RFC 8484, don't loop on the resolver name."
Sure, that's fine.
Yeah, this paragraph is old and can be removed.
Looks good! Just silly editorial nits

should be able to use those records while safely ignoring the third record.  <ins> To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of RFC8484.  Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of RFC8484. </ins> This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-


policy or user input.  Details of such policy are out of scope of this document.  Clients MUST NOT automatically use a Designated Resolver without some sort of validation, such as the two methods <del> defined in this document or a future mechanism. </del>  A client MUST NOT re-use a designation discovered using the IP address of one Unencrypted DNS Resolver in place of any other

policy or user input.  Details of such policy are out of scope of this document.  Clients MUST NOT automatically use a Designated Resolver without some sort of validation, such as the two methods  <ins> defined in this document or a future mechanism.  Use without validation can allow an attacker to direct traffic to an Encrypted Resolver that is unrelated to the original Unencrypted DNS Resolver, as described in security. </ins> A client MUST NOT re-use a designation discovered using the IP address of one Unencrypted DNS Resolver in place of any other


address on multiple different networks, a Designated Resolver that has been discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery process for each <del> network. However, if a given Unencrypted DNS Resolver designates a Designated Resolver that does not use a private or local IP address and can be verified using the mechanism described in verified, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in verified.  This is a tradeoff between performance (by having no delay in establishing an encrypted DNS connection on the new network) and functionality (if the Unencrypted DNS Resolver intends to designate different Designated Resolvers based on the network from which clients connect). </del>  4.2.

address on multiple different networks, a Designated Resolver that has been discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery process for each  <ins> network, since the same IP address may be used for different servers on the different networks. </ins> 4.2.


possible. If these checks fail, the client MUST NOT automatically use the <del> discovered Designated Resolver.  Additionally, the client SHOULD </del>  suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for the length of time indicated by the SVCB record's Time to Live (TTL) in order to avoid excessive queries that

possible. If these checks fail, the client MUST NOT automatically use the  <ins> discovered Designated Resolver if this designation was only discovered via a "_dns.resolver.arpa." query (if the designation was advertised directly by the network as described in dnr-interaction, the server can still be used).  Additionally, the client SHOULD </ins> suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for the length of time indicated by the SVCB record's Time to Live (TTL) in order to avoid excessive queries that


If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check <del> (opportunistic). </del>  <del> If resolving the name of a Designated Resolver from an SVCB record yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query, the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known and validated IP address for the same Designated Resolver name. </del>  4.3.

If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check  <ins> (opportunistic).  If the IP address is not shared, opportunistic use allows for attackers to redirect queries to an unrelated Encrypted Resolver, as described in security. </ins>  <ins> Connections to a Designated Resolver can use a different IP address than the IP address of the Unencrypted DNS Resolver, such as if the process of resolving the SVCB service yields additional addresses. Even when a different IP address is used for the connection, the TLS certificate checks described in this section still apply for the original IP address of the Unencrypted DNS Resolver. </ins> 4.3.


6.4. DNS resolvers that support DDR by responding to queries for <del> _dns.resolver.arpa SHOULD treat resolver.arpa as a locally served zone per RFC6303.  In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under </del>  resolver.arpa with NODATA. 6.5.

6.4. DNS resolvers that support DDR by responding to queries for  <ins> _dns.resolver.arpa MUST treat resolver.arpa as a locally served zone per RFC6303.  In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under </ins> resolver.arpa with NODATA. 6.5.


Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS <del> server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </del>  DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the

Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS  <ins> server.  For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to use encrypted DNS. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the


client or network. If the IP address of a Designated Resolver differs from that of an Unencrypted DNS Resolver, clients applying Verified Discovery (verified) MUST validate that the IP address of the Unencrypted DNS Resolver is covered by the SubjectAlternativeName of the Designated


Clients using Opportunistic Discovery (opportunistic) MUST be limited to cases where the Unencrypted DNS Resolver and Designated Resolver <del> have the same IP address.  Clients which do not follow Opportunistic Discovery (opportunistic) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain </del>  control of the Unencrypted DNS Resolver. The constraints on the use of Designated Resolvers specified here

Clients using Opportunistic Discovery (opportunistic) MUST be limited to cases where the Unencrypted DNS Resolver and Designated Resolver  <ins> have the same IP address, which SHOULD be a private or local IP address.  Clients which do not follow Opportunistic Discovery (opportunistic) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain </ins> control of the Unencrypted DNS Resolver. The constraints on the use of Designated Resolvers specified here


This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".)  4.3. These SvcParamKeys from SVCB apply to the "dns" scheme without

Closes URL
Allowing the use of nonstandard port numbers in SVCB for DNS provides valuable operational flexibility, but it also creates a risk related to cross-protocol confusion attacks, in which a malicious server convinces a client to send TCP contents that can be misparsed as a different protocol by a non-TLS victim server. For example, a malicious DNS server could indicate an SNI or session ticket that can be misparsed as a command by a recipient server, and use DNS rebinding to change its own apparent IP address to the victim server. Clients would then send this server-controlled payload to the victim server. This is dangerous if the client is implicitly authorized to control the victim server (e.g. authorization by IP address). Note that only DoT and DoH (over TCP) are amenable to these attacks. QUIC Initial encryption ensures that the packet has no meaning to a recipient that is not QUIC-aware, and any QUIC-aware recipient should not be vulnerable to these attacks. We should consider ways to minimize the impact of these attacks. For example, we could require clients to restrict the value of the parameter to a small fixed list, or refer to the . Credit to NAME

This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) <ins> Support for the "port" key can be unsafe if the client has implicit elevated access to some network service (e.g. a local service that is inaccessible to remote parties) and that service uses a TCP-based protocol other than TLS.  A hostile DNS server might be able to manipulate this service by causing the client to send a specially crafted TLS SNI or session ticket that can be misparsed as a command or exploit.  To avoid such attacks, clients SHOULD NOT support the "port" key unless one of the following conditions applies: The client is being used with a DNS server that it trusts not attempt this attack. The client is being used in a context where implicit elevated access cannot apply. The client restricts the set of allowed TCP port values to exclude any ports where a confusion attack is likely to be possible (e.g. the "bad ports" list from the "Port blocking" section of FETCH). </ins> 4.3. These SvcParamKeys from SVCB apply to the "dns" scheme without


defined for the DNS. Note that this document only clarifies requirements of name server <del> software implementations.  It does not change any requirements on data placed in DNS zones or registries. </del>  1.1.

…out presence of glue in zones.
No further discussion on list nor here so I will merge this.
From the dnsop list, Ralf Weber suggests the draft could more clearly state that a name server might provide an "incorrect" response because it wasn't given necessary glue records in the zone data.

defined for the DNS. Note that this document only clarifies requirements of name server  <ins> software implementations.  It does not introduce or change any requirements on data placed in DNS zones or registries.  In other words, this document only makes requirements on "available glue records" (i.e., those given in a zone), but does not make requirements regarding their presence in a zone.  If some glue records are absent from a given zone, an authoritative name server may be unable to return a useful referral response for the corresponding domain.  The IETF may want to consider a separate update to the requirements for including glue in zone data, beyond those given in RFC1034 and RFC1035. </ins> 1.1.


5. This section defines the terms used for the systems that act as DNS <del> clients, DNS servers, or both. </del>  For terminology specific to the public DNS root server system, see RSSAC026.  That document defines terms such as "root server", "root

…empt to define "resolve" and "resolution".
This issue concerns consistency and definition of some terms in the document. "Name server", "name server" and, perhaps, "server" seem to be used interchangeably. None of those terms have a formal definition in the document. The terms are also used in conjunction with various modifiers like "authoritative server", "DNS server", etc. While all those terms are likely pretty well-known, for the purposes of this document, un my opinion, it would be helpful to give a generic definition of "server", and how it is then combined with modifiers to form terminology for specific types of servers. Based on the definition of "server", it would be helpful to include a definition for "name server", "name server" or "DNS server" (pick one) and then use that term uniformly throughout the document.
Added a note about this in URL
Fixed in
These are common terms that are used in contexts that are not always associated with the resolver itself, so they should have stand-alone definitions.
First attempt at definition in URL

5. This section defines the terms used for the systems that act as DNS  <ins> clients, DNS servers, or both.  In the RFCs, DNS servers are sometimes called "name servers", "nameservers", or just "servers". There is no formal definition of DNS server, but the RFCs generally assume that it is an Internet server that listens for queries and sends responses using the DNS protocol defined in RFC1035 and its successors. </ins> For terminology specific to the public DNS root server system, see RSSAC026.  That document defines terms such as "root server", "root


of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context.  A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function.  Stub resolvers are discussed but

of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. <ins> A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and receiving some sort of answer".  Similarly, an imputed definition of "resolution" might be "the answer received from resolving". </ins> A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function.  Stub resolvers are discussed but


simplifications are available.  Instead of being configured with (or discovering) the service registration domain, the (proposed) special- use domain name (see RFC6761) "default.service.arpa" is used.  The <del> details of how SRP server(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </del>  mechanism here. <del> SRP clients on constrained networks are expected to receive from the network a list of SRP servers with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP server addresses.  It is the responsibility of the SRP server supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </del>  2.1.3.

This is part of the previous pull request, but I missed it because it was interleaved with some unrelated changes.

simplifications are available.  Instead of being configured with (or discovering) the service registration domain, the (proposed) special- use domain name (see RFC6761) "default.service.arpa" is used.  The  <ins> details of how SRP registrar(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </ins> mechanism here.  <ins> SRP requestors on constrained networks are expected to receive from the network a list of SRP registrars with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP registrar addresses.  It is the responsibility of the SRP registrar supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </ins> 2.1.3.


An instruction is a Host Description Instruction if, for the appropriate hostname, it contains  2.3.2. An SRP Update MUST include zero or more Service Discovery

The set of constraints for the host description includes a constrain that A and AAAA records must be of sufficient scope. This is asking a bit much of the SRP server, which may or may not be able to make this determination. There may also be cases where an SRP registration with an address of less than global scope is useful. Consequently, this constraint is removed, and text added to talk about how servers should deal with addresses of less-than-global scope.

An instruction is a Host Description Instruction if, for the appropriate hostname, it contains <ins> A and/or AAAA records that are not of of sufficient scope to be validly published in a DNS zone can be ignored by the SRP server, which could result in a host description effectively containing zero reachable addresses even when it contains one or more addresses. For example, if a link-scope address or IPv4 autoconfiguration address is provided by the SRP requestor, the SRP registrar could not publish this in a DNS zone.  However, in some situations, the SRP registrar may make the records available through a mechanism such as an advertising proxy only on the specific link from which the SRP update originated; in such a situation, locally-scoped records are still valid. </ins> 2.3.2. An SRP Update MUST include zero or more Service Discovery


Service Registration Protocol for DNS-Based Service Discovery <del> draft-ietf-dnssd-srp-13 </del>  Abstract

Update the draft number, date, and change draft-sekar-ul to draft-ietf-dnssd-update-lease.

Service Registration Protocol for DNS-Based Service Discovery  <ins> draft-ietf-dnssd-srp-14 </ins> Abstract


record MUST contain the same public key.  The update is signed using SIG(0), using the private key that corresponds to the public key in the KEY record.  The lifetimes of the records in the update is set <del> using the EDNS(0) Update Lease option I-D.sekar-dns-ul. </del>  The KEY record in Service Description updates MAY be omitted for brevity; if it is omitted, the SRP registrar MUST behave as if the

record MUST contain the same public key.  The update is signed using SIG(0), using the private key that corresponds to the public key in the KEY record.  The lifetimes of the records in the update is set  <ins> using the EDNS(0) Update Lease option I-D.ietf-dnssd-update-lease. </ins> The KEY record in Service Description updates MAY be omitted for brevity; if it is omitted, the SRP registrar MUST behave as if the


Because the DNS-SD registration protocol is automatic, and not managed by humans, some additional bookkeeping is required.  When an update is constructed by the SRP requestor, it MUST include an <del> EDNS(0) Update Lease Option I-D.sekar-dns-ul.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </del>  These leases are promises, similar to RFC2131, from the SRP requestor that it will send a new update for the service registration before

Because the DNS-SD registration protocol is automatic, and not managed by humans, some additional bookkeeping is required.  When an update is constructed by the SRP requestor, it MUST include an  <ins> EDNS(0) Update Lease Option I-D.ietf-dnssd-update-lease.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </ins> These leases are promises, similar to RFC2131, from the SRP requestor that it will send a new update for the service registration before


There are two primary use cases for this protocol. <del> The primary one is to prevent on-path network devices from </del>  interfering with native DNS operations.  This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are

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.

There are two primary use cases for this protocol.  <ins> The primary use case is to prevent on-path network devices from </ins> interfering with native DNS operations.  This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are


A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done <del> in a way consistent with the cross-origin resource sharing CORS security model of the web and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </del>  using a different media type than traditional clients. <del> [ This paragraph is to be removed when this document is published as an RFC ] Note that these use cases are different than those in a </del>  similar protocol described at I-D.ietf-dnsop-dns-wireformat-http. The use case for that protocol is proxying DNS queries over HTTP instead of over DNS itself.  The use cases in this document all

A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done  <ins> in a way consistent with the cross-origin resource sharing security model of the web CORS and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </ins> using a different media type than traditional clients.  <ins> [[ This paragraph is to be removed when this document is published as an RFC ]] Note that these use cases are different than those in a </ins> similar protocol described at I-D.ietf-dnsop-dns-wireformat-http. The use case for that protocol is proxying DNS queries over HTTP instead of over DNS itself.  The use cases in this document all


defined. The protocol must use a secure transport that meets the <del> requirements for modern https://. </del>  4.1.

defined. The protocol must use a secure transport that meets the  <ins> requirements for modern HTTPS. </ins> 4.1.


5.1. The media type is "application/dns-udpwireformat".  The body is the <del> DNS on-the-wire format is defined in RFC1035.  The body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. </del>  DNS API clients using the DNS wire format MAY have one or more EDNS(0) extensions RFC6891 in the request.

5.1. The media type is "application/dns-udpwireformat".  The body is the  <ins> DNS on-the-wire format is defined in RFC1035. When using the GET method, the body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. When using the POST method, the body is not encoded. </ins> DNS API clients using the DNS wire format MAY have one or more EDNS(0) extensions RFC6891 in the request.


At the time this is published, the response types are works in progress.  The only known response type is "application/dns- <del> udpwireformat", but it is likely that at least one JSON-based </del>  response format will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY

At the time this is published, the response types are works in progress.  The only known response type is "application/dns-  <ins> udpwireformat", but it is possible that at least one JSON-based </ins> response format will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY


7. <del> In order to satisfy the security requirements of DNS over HTTPS, this protocol MUST use HTTP/2 RFC7540 or its successors.  HTTP/2 enforces a modern TLS profile necessary for achieving the security requirements of this protocol. </del> This protocol MUST be used with https scheme URI RFC7230. <del> The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression. For this additional reason, this protocol MUST use HTTP/2 RFC7540 or its successors. </del>  8.

7.  This protocol MUST be used with https scheme URI RFC7230.  <ins> This protocol MUST use HTTP/2 RFC7540 or its successors in order to satisfy the security requirements of DNS over HTTPS.  Further, the messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression, all of which are supported by HTTP/2 RFC7540 or its successors. </ins> 8.


9. <del> Running DNS over https:// relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS this protocol expects to use current best practices for secure </del>  transport. Session level encryption has well known weaknesses with respect to

9.  <ins> Running DNS over HTTPS relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure </ins> transport. Session level encryption has well known weaknesses with respect to


1. <del> The Internet does not always provide end to end reachability for native DNS.  On-path network devices may spoof DNS responses, block DNS requests, or just redirect DNS queries to different DNS servers that give less-than-honest answers.  These are also sometimes delivered with poor performance or reduced feature sets. Over time, there have been many proposals for using HTTP and HTTPS as a substrate for DNS queries and responses.  To date, none of those proposals have made it beyond early discussion, partially due to disagreement about what the appropriate formatting should be and partially because they did not follow HTTP best practices. </del> This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and

This text is great justification to include in a charter, but this is a protocol specification and it really doesn't add much.
It seemed like the WG wanted the document to be shorter and more specific, so this feels good.

1.  This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and


3.  The protocol described here bases its design on the following protocol requirements:

… but keep the requirement for future formats.
Attempts to
As input to the process, this was extremely valuable, but now that this is in WGLC, we're done with it. Does the audience of the ultimate RFC need this information? The only thing that I can see that is worth salvaging is a statement to the effect that DNS64 isn't explicitly supported.
Yes, we still need it. We have not gone to IETF Last Call and, despite what some people think, the IETF gets to change a protocol significantly during IETF Last Call. But even after that, once it is an RFC, others will want to update the RFC. It is important to keep the requirements for them as well.
Actually, we probably don't need it in the RFC as long as the one future requirement (for formats) is still there. Please see PR

3. <ins> [[ RFC Editor: Please remove this entire section before publication. ]] </ins> The protocol described here bases its design on the following protocol requirements:


In order to maximize interoperability, DNS API clients and DNS API servers MUST support the "application/dns-message" media type.  Other media types MAY be used as defined by HTTP Content Negotiation <del> (RFC7231 Section 3.4). </del>  6.

In order to maximize interoperability, DNS API clients and DNS API servers MUST support the "application/dns-message" media type.  Other media types MAY be used as defined by HTTP Content Negotiation  <ins> (RFC7231 Section 3.4).  Those media types MUST be flexible enough to express every DNS query that would normally be sent in DNS over UDP (including queries and responses that use DNS extensions, but not those that require multiple responses). </ins> 6.


are independent and fully compatible protocols, each solving different problems.  The use of one does not diminish the need nor the usefulness of the other.  It is the choice of a client to either <del> perform full DNSSEC validation of answers or to treat answers from a DNS API server as DNSSEC-authenticated, and this choice may be affected by the response media type. </del>  caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect

…raft-ietf-doh-dns-over-https/commit/3f74bd6e0760f96717ffd3e667a37e13b45839c4#commitcomment-28865666 and URL that this wording is much clearer.
Sara, making this pr was on my todo list - thanks for the time saver. Paul sent me an IM about it, so I'll ga and merge.

are independent and fully compatible protocols, each solving different problems.  The use of one does not diminish the need nor the usefulness of the other.  It is the choice of a client to either  <ins> perform full DNSSEC validation of answers or to trust the DNS API server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not.  As noted in http-response, different response media types will provide more or less information from a DNS response so this choice may 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


security implications of HTTP caching for other protocols that use HTTP. <del> In the absence of information about the authenticity of responses, such as DNSSEC, a DNS API server can give a client invalid data in </del>  responses.  A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration.  This does not guarantee

security implications of HTTP caching for other protocols that use HTTP.  <ins> In the absence of DNSSEC information about the authenticity of responses a DNS API server can give a client invalid data in </ins> responses.  A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration.  This does not guarantee


configuration.  This does not guarantee protection against invalid data but reduces the risk. <del> 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 and authenticity expected by the user of the client. </del> 10. Local policy considerations and similar factors mean different DNS

this paragraph is true.. but its a tad confusing and I don't think really describes anything germane to doh.
NAME WFM to just remove this text

configuration.  This does not guarantee protection against invalid data but reduces the risk.  10. Local policy considerations and similar factors mean different DNS


This protocol MUST be used with the https scheme URI RFC7230.  6.1. A DoH exchange can pass through a hierarchy of caches that include

Is there a reason not to make a recommendation for the case of a DOH-only service? The current text says: Implementations of DoH clients and servers need to consider the benefit and privacy impact of all these features, and their deployment context, when deciding whether or not to enable them. Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."?
NAME That could be added, but it would need a lot more text because your proposed text only deals with one layer (HTTP) while the text above it also talks about fingerprinting with TLS, TCP, and IP (in reverse order). The WG can decide whether adding recommendations for just one layer is worthwhile or possibly misleading about the overall privacy.
NAME It was only an example, and I would be happy to expand. That said, I think this is the most likely source of leakage: folks using a general purpose HTTP subsystem that carries information not needed for DOH requests. Actually recommending data minimization there, rather than saying "it should be considered" seems like a worthwhile thing to do in my personal opinion.
Agreed with Ted (on the list) that this conversation should be on the list. Locking it here.
I have unlocked the comments so that people can propose specific wording changes as diffs in the PR itself; most questions and suggestions should be done on the list.

This protocol MUST be used with the https scheme URI RFC7230. <ins> PrivacyConsiderations and Security discuss additional considerations for the integration with HTTP. </ins> 6.1. A DoH exchange can pass through a hierarchy of caches that include


7. The data payload for the application/dns-message media type is a <del> single message of the DNS on-the-wire format defined in section 4.2.1 </del>  of RFC1035.  The format was originally for DNS over UDP.  Although RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This media type restricts the maximum size of the DNS message to 65535 bytes.  Note that the wire format used in this media type is different than the wire format used <del> in RFC7858 (which uses the format defined in section 4.2.2 of </del>  RFC1035). DoH clients using this media type MAY have one or more EDNS options

7. The data payload for the application/dns-message media type is a  <ins> single message of the DNS on-the-wire format defined in Section 4.2.1 </ins> of RFC1035.  The format was originally for DNS over UDP.  Although RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This media type restricts the maximum size of the DNS message to 65535 bytes.  Note that the wire format used in this media type is different than the wire format used  <ins> in RFC7858 (which uses the format defined in Section 4.2.2 of </ins> RFC1035). DoH clients using this media type MAY have one or more EDNS options


9.  Running DNS over HTTPS relies on the security of the underlying HTTP transport.  This mitigates classic amplification attacks for UDP- based DNS.  Implementations utilizing HTTP/2 benefit from the TLS

9. <ins> RFC7626 discusses DNS Privacy Considerations in both "On the wire" (Section 2.4), and "In the server" (Section 2.5) contexts.  This is also a useful framing for DoH's privacy considerations. 9.1. DoH encrypts DNS traffic and requires authentication of the server. This mitigates both passive surveillance RFC7258 and active attacks that attempt to divert DNS traffic to rogue servers (RFC7626 Section 2.5.1).  DNS over TLS RFC7858 provides similar protections, while direct UDP and TCP based transports are vulnerable to this class of attack. Additionally, the use of the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter unprivileged on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult. 9.2. A DoH implementation is built on IP, TCP, TLS, and HTTP.  Each layer contains one or more common features that can be used to correlate queries to the same identity.  DNS transports will generally carry the same privacy properties of the layers used to implement them. For example, the properties of IP, TCP, and TLS apply to DNS over TLS implementations. The privacy considerations of using the HTTPS layer in DoH are incremental to those of DNS over TLS.  DoH is not known to introduce new concerns beyond those associated with HTTPS. At the IP level, the client address provides obvious correlation information.  This can be mitigated by use of a NAT, proxy, VPN, or simple address rotation over time.  It may be aggravated by use of a DNS server that can correlate real-time addressing information with other personal identifiers, such as when a DNS server and DHCP server are operated by the same entity. TCP-based solutions may seek performance through the use of TCP Fast Open RFC7413.  The cookies used in TCP Fast Open allow servers to correlate TCP sessions together. TLS based implementations often achieve better handshake performance through the use of some form of session resumption mechanism such as session tickets RFC5077.  Session resumption creates trivial mechanisms for a server to correlate TLS connections together. HTTP's feature set can also be used for identification and tracking in a number of different ways.  For example, authentication request header fields explicitly identify profiles in use, and HTTP Cookies are designed as an explicit state tracking mechanism between the client and serving site and often are used as an authentication mechanism. Additionally, the User-Agent and Accept-Language request header fields often convey specific information about the client version or locale.  This facilitates content negotiation and operational work- arounds for implementation bugs.  Request header fields that control caching can expose state information about a subset of the client's history.  Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation. The DoH protocol design allows applications to fully leverage all the features of the HTTP ecosystem, including features not enumerated here.  Implementations of DoH clients and servers need to consider the benefit and privacy impact of these features, and their deployment context, when deciding whether or not to enable them. Implementations are advised to expose the minimal set of data needed to achieve the desired feature set. Determining whether or not a DoH implementation requires HTTP cookie RFC6265 support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP.  HTTP Cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case. 10. </ins> Running DNS over HTTPS relies on the security of the underlying HTTP transport.  This mitigates classic amplification attacks for UDP- based DNS.  Implementations utilizing HTTP/2 benefit from the TLS


This prohibition does not guarantee protection against invalid data, but it does reduce the risk. <del> 10. </del>  Local policy considerations and similar factors mean different DNS servers may provide different results to the same query: for instance

This prohibition does not guarantee protection against invalid data, but it does reduce the risk.  <ins> 11. </ins> Local policy considerations and similar factors mean different DNS servers may provide different results to the same query: for instance


to support reordering, parallelism, priority, and header compression to acheive similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of <del> conveying the semantic requirements of DOH but would result in very </del>  poor performance for many uses cases. 8.

This text is rather subjective without data. Changing it to "may" still brings the point without needing a reference to a study proving the sentence true.
(whoops; just realized I've been blowing my pull requests by chaining them off a single branch... my bad, and this will cause you some pain)

to support reordering, parallelism, priority, and header compression to acheive similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of  <ins> conveying the semantic requirements of DOH but may result in very </ins> poor performance for many uses cases. 8.


Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party.  11. Joe Hildebrand contributed lots of material for a different iteration

this is a little longer than I had hoped given that bootstrap deadlock is not a new problem for dns introduced by doh.. but the https validaton angle is worth mentioning.
If DOH uses https under the hood, how does this https host name get resolved? I would have expected this to be mentioned in the RFC, though I didn't see any mention of it, besides OCSP Stapling. Is it assumed that DOH would need to be bootstrapped by traditional DNS? Or is it assumed that a DOH endpoint would have a TLS/SSL certificate for its ip address? (Apparently a certificate for an IP address is possible in some cases, though hard to get.) I assume DOH is not intended to be used by home NAT routers? (How would the router get a signed TLS certificate? Maybe a DHCP response could say: use this DOH url and trust this self-signed cert for its ip address (though a certificate might be too big for a DHCP response). Or, in cases where no local DNS services are needed, the DHCP response could maybe say: use this public DOH url, here's the ip address for that hostname)
The document doesn't describe how a HTTPS client authenticates HTTPS... that's on purpose in order to simply leverage HTTPS without surprises. as a practical matter a number of things can be done. One is TOFU as you suggest. Another is an IP based certificate which you also suggest. Another would be to lookup the name via another, perhaps less trusted resolver, knowing that HTTPS means the IP address isn't part of the security scheme anyhow - its just a route.. subject to blocking, but not to impersonation. Another would be to bootstrap the client with a name and an address instead of one or the other. but as a general matter I think this is one step beyond the scope of the document as its basically writing down the rules for HTTPS.
This issue semi-duplicates
I think this should at least be called out as an operational concern. e.g. mentioning that you probably need an alternate resolver to find the DOH server, after which a paranoid implementation can re-query for the DOH's address as an integrity check.
This is the direction I have taken for . When opening a connection to the remote DOH server, if an ip was provided, it will just use that, if not, it will try to resolve using the local stub, but that may not work.... Just like an IP has always been provided to bootstrap which nameserver to use, here we need to also be provided a name so we can validate that the server we are talking to is the one we trust.

Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party. <ins> A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be originally determined from that same server, a DOH client cannot use its DOH server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API Server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS. </ins> 11. Joe Hildebrand contributed lots of material for a different iteration


Error alert message.  In earlier versions of TLS, error alerts could be warnings or fatal.  In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and <del> "user_cancelled", both of which indicate that the connection is not </del>  going to continue normally, see RFC8446. In TLS 1.3 RFC8446, error alerts are not mandatory to send after a

Update the draft to use the same spelling as TLS RFC uses. Relates to issue
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.
This looks good to merge

Error alert message.  In earlier versions of TLS, error alerts could be warnings or fatal.  In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and  <ins> "user_canceled", both of which indicate that the connection is not </ins> going to continue normally, see RFC8446. In TLS 1.3 RFC8446, error alerts are not mandatory to send after a


maintain backwards compatibility.  However, this document does provide additional guidance on authentication, authorization, and resumption for EAP-TLS regardless of the underlying TLS version used. <del> This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </del>  This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use TLS 1.3.  The specification for how other

Hi! I performed a second AD review on draft-ietf-emu-eap-tls13. This time on -18. Thank you to the authors, the responsible co-chair, and the WG for all of the work to redesign the -13 protocol in response to the initial IESG review in December 2020. My review feedback consists of my own minimal additional comments and highlights of where previously stated IESG ballot items do not appear to be responded to or addressed. All items appear to be minor. ** Section 2.4. Previously, this text referenced TLS 1.3 or higher necessitating more ambiguous reference to version numbers. However, now the text only notes TLS 1.3. OLD When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) for the TLS version used. For TLS 1.3 the compliance requirements are defined in Section 9 of [RFC8446]. NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. ==[ COMMENT (Ben Kaduk) Section 2.1.4 The two paragraphs below replaces the corresponding paragraphs in Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of [RFC5216] still apply with the exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with the EAP-TLS server sending an EAP-Success message. If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. Just to walk through the various scenarios here; if the last message of the TLS handshake for a given TLS version is sent by the TLS client, that will go in an EAP-Response, so the server is then able to send EAP-Success directly. On the other hand, if the last TLS handshake message is sent by the server, that will have to go in an EAP-TLS EAP-Request, and so the peer will have to send an empty EAP-TLS response in order for the server to be able to wend EAP-Success? Do we need to have any text here to handle that empty EAP-TLS Eap-Request case? ==[ COMMENT(Alvaro Retana) Is the intention of the Appendix to provide additional formal updates to rfc5216? That is what it looks like to me, but there's no reference to it from the main text. Please either reference the Appendix when talking about some of the other updates (if appropriate) or specifically include the text somewhere more prominent. [Roman] As proposed above, please provide some forward reference. ==[ COMMENT (Éric Vyncke) I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous as it the 'updated section' is not identified clearly. I.e., as the sections in RFC 5216 are not too long, why not simply providing whole new sections ? [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216) ==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Regards, Roman
==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Eric is correct that US english i.e. and e.g. is usually followed by a comma. I corrected this in d9f5028 I also run a word spell check on the document. Word does not suggest removing any comma after "but" but rather insert an additional comma after a but. I think this can be left to the RFC editor. The word spell check caught two other grammar errors (s after plural, no s after singular) RFC 8446 does not use capitalization on post-handshake as that is just a name for a set of messages. I corrected these things in
I Made a new PR
Made a commit with NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446].
Section 2.1.4 Changed the text to: The message flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server.
I added a forward reference to the appendix in the introduction
NAME looks like you have got everything covered? are there any comments from Roman which still need to be addressed? should we submit a new version and ask for IETF last call?
I have tried to do everything. Problem with the updates thing. The replace or amend strategy does not really work.... [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216)
NAME We should likely not do to much changes. Maybe we can write something like Amends with the following text. TLS 1.2 specific details in RFC 5216 are replaced. Requirement in the new takes precedence over requirements in the old text.
This review was addressed in earlier submissions. closing

maintain backwards compatibility.  However, this document does provide additional guidance on authentication, authorization, and resumption for EAP-TLS regardless of the underlying TLS version used.  <ins> This document only describes differences compared to RFC5216.  When EAP-TLS is used with TLS 1.3, some references are updated as specified in updateref.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </ins> This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use TLS 1.3.  The specification for how other


If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.  The message <del> flow ends with the EAP-TLS server sending an EAP-Success message. </del>  If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing

If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.  The message  <ins> flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server. </ins> If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing


When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange <del> algorithms, extensions, etc.) for the TLS version used.  For TLS 1.3 the compliance requirements are defined in Section 9 of RFC8446.  In </del>  EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL be supported.

When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange  <ins> algorithms, extensions, etc.) defined in Section 9 of RFC8446.  In </ins> EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL be supported.


1.2. <del> A frequently emphasized advantage of XML is the availability of powerful tools to analyse, transform and selectively extract data from XML documents.  XPath is one of these tools. </del>  <del> In 2007, the need for something solving the same class of problems for the emerging JSON community became apparent, specifically for: Finding data interactively and extracting them out of RFC8259 JSON values without special scripting. Specifying the relevant parts of the JSON data in a request by a client, so the server can reduce the amount of data in its response, minimizing bandwidth usage. So what does such a tool look like for JSON?  When defining a JSONPath, how should expressions look? The XPath expression looks like or in popular programming languages such as JavaScript, Python and PHP, with a variable x holding the argument.  Here we observe that such languages already have a fundamentally XPath-like feature built in. The JSONPath tool in question should: be naturally based on those language characteristics. cover only essential parts of XPath 1.0. be lightweight in code size and memory consumption. </del>  <del> be runtime efficient. </del>  <del> 1.3. </del>  <del> JSONPath expressions always apply to a value in the same way as XPath expressions are used in combination with an XML document.  Since a value is anonymous, JSONPath uses the abstract name "$" to refer to the root node of the argument. </del>  JSONPath expressions can use the or the <del> for paths input to a JSONPath processor.  [1] Where a JSONPath processor uses JSONPath expressions as output paths, these will always be converted to Output Paths which employ the more general .  [2] Bracket notation is more general than dot notation and can serve as a canonical form when a JSONPath processor uses JSONPath expressions as output paths. JSONPath allows the wildcard symbol "*" for member names and array indices.  It borrows the descendant operator ".." from E4X and the array slice syntax proposal "[start:end:step]" SLICE from ECMASCRIPT 4. JSONPath was originally designed to employ an </del>  <del> for computing expressions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform. </del>  <del> JSONPath can use expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in: </del>  <del> The symbol "@" is used for the current node.  Filter expressions are supported via the syntax "?(<boolean expr>)" as in </del>  <del> Here is a complete overview and a side by side comparison of the JSONPath syntax elements with their XPath counterparts. </del>  <del> XPath has a lot more to offer (location paths in unabbreviated syntax, operators and functions) than listed here.  Moreover there is a significant difference how the subscript operator works in Xpath and JSONPath: </del>  <del> Square brackets in XPath expressions always operate on the resulting from the previous path fragment.  Indices always start at 1. With JSONPath, square brackets operate on the or addressed by the previous path fragment.  Array indices always start at 0. </del>  2.

Thanks for merging. I had a small fix to the caption of table 1 which is now .
(This was original raised in and now being split out) (Michael Kay) want to confuse the JSONPath spec by going into detailed comparisons at the risk of contradicting the normative text. (Glyn Normington) (Michael Kay) It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here. At the IETF 110 meeting consensus was raised that inclusion of XPath in the Appendix section would be the most appropriate way to reference to it.
Closed in
Great improvement!Additions / Replacements of high value ... thanks

1.2.  <ins> This document picks up Stefan Goessner's popular JSONPath specification dated 2007-02-21 JSONPath-orig and provides a normative definition for it. inspired-by-xpath provides a brief synopsis with XML's XPath XPath, which was the inspiration that led to the definition of JSONPath. JSONPath was intended as a light-weight companion to JSON implementations on platforms such as PHP and JavaScript, so instead of defining its own expression language like XPath did, JSONPath delegated this to the expression language of the platform.  While the languages in which JSONPath is used do have significant commonalities, over time this caused non-portability of JSONPath expressions between the ensuing platform-specific dialects. The present specification intends to remove platform dependencies and server as a common JSONPath specification that can be used across platforms.  Obviously, this means that backwards compatibility could not always be achieved; a design principle of this specification is to go with a "consensus" between implementations even if it is rough, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language. </ins>  <ins> 1.3. </ins>  <ins> JSONPath expressions are applied to a JSON value, the </ins>  <ins> .  Within the JSONPath expression, the abstract name "$" is used to refer to the </ins>  <ins> of the argument, i.e., to the argument as a whole. </ins> JSONPath expressions can use the or the  <ins> to build paths that are input to a JSONPath processor.  Bracket notation is more general than dot notation and can serve as a canonical form (for instance, when a JSONPath processor uses JSONPath expressions as output paths). </ins>  <ins> JSONPath allows the wildcard symbol "*" to select any member of an object or any element of an array (wildcard).  The descendant operator ".." selects the node and all its descendants (descendant- selector).  The array slice syntax "[start:end:step]" allows selecting a regular selection of an element from an array, giving a start position, an end position, and possibly a step value that moves the position from the start to the end (slice). </ins>  <ins> JSONPath employs an </ins>  <ins> for computing values and making decisions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform.  JSONPath can use such expression language expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in [no-dot-length]: </ins>  <ins> The symbol "@" is used for the current node, i.e., the node in the context of which the expression is evaluated. </ins>  <ins> Filter expressions are supported via the syntax "?(<boolean expr>)" as in </ins>  <ins> tbl-overview provides a quick overview of the JSONPath syntax elements. </ins> 2.


3.5.7.2. <del> The "descendant-selector" is inspired by ECMAScript for XML (E4X). It selects the node and all its descendants. </del>  3.5.8.

3.5.7.2.  <ins> The "descendant-selector" selects the node and all its descendants. </ins> 3.5.8.


isolating a single location within a document. Path is a query syntax that can also be used to pull multiple locations. <ins> [no-dot-length] We probably want to use an expression that does not use </ins>


The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in a object, and to perform numeric comparisons of member <del> values with a constant. </del>  3.

Lots of niggly details re blank space. Style consistency, some missing places (assuming we stick with the liberal approach). Allowing "in" before or after a newline or tab. Adding some legend to the only remaining table with XPath content in the main document.
[ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be (Do not use the term "whitespace" any more.) Task "T1" in the document URL
and
From the document: (whitespace is now generally called blank space, but that doesn't change the work to be done.)
and
How much do we want to reference XPath within the spec? I understand that XPath is the inspiration (and in the tagline that NAME used in his blog post: "XPath for JSON"), but I wonder if much of this can be left out of the spec. The argument for this is that we're defining JSONPath. It shouldn't assume any understanding of XPath or any other technology. It's not the job of the specification to convince readers to use it. It's the job of the specification to define the technology. I'm perfectly happy moving this into an external "Understanding JSONPath" website at some point.
I seem to remember that last time we discussed this we agreed to move the introductory comparison with XPath to an appendix, with the possible exception of the overview table (but that could be duplicated).
The XPath inclusion was moved into an appendix.
Do we allow spaces (outside of string literals)? If so, where is whitespace allowed? I think whitespace in query expressions should be allowed. This would fall in to the context of the . Maybe inside the union/ selector: Are there any other places where whitespace could be considered useful?
It may be convenient to allow spaces between matchers - to allow well-readable multi-line queries for complex cases.
Looks like the allows whitespace internally, so that (with leading and trailing whitespace) is valid.
Closed in and
What was the resolution here? Where did we end up allowing whitespace?

The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in a object, and to perform numeric comparisons of member  <ins> values with a constant.  For further illustration, the table shows XPath expressions that would be used with a comparable XML document; see also xpath-overview. </ins> 3.


member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]". <del> Next, "[*]" selects from any input node -- either an array or an object -- all its elements or members.  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </del>  Finally, ".b" selects from any input node of type object with a member name "b" and selects the node of the member value of the input

member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]".  <ins> Next, "[*]" selects from an input node of type array all its elements (if the input note were of type object, it would select all its member values, but not the member names).  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </ins> Finally, ".b" selects from any input node of type object with a member name "b" and selects the node of the member value of the input


Regular expression tests can be applied to "string" values only. <del> The value of the first operand ("containable") of a "contain-expr" is compared to every single element of the RHS "container".  In case of a match a selection occurs.  Containment tests -- like comparisons -- are restricted to primitive values.  So even if a structured "containable" value is equal to a certain structured value in "container", no selection is done. The value of the second operand ("container") of a "contain-expr" needs to be resolved to an array.  Otherwise nothing is selected. </del> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).

From the meeting at IETF 112 ([1]): Consensus: 'in' won't be used, but it will be easy to add later if there's real demand [1] URL
Good eyes. Thanks!
Yes, we agreed to remove the 'in' operator as some kind of syntactic sugar. thanks
Thanks! I pushed a small commit removing an "in" example.

Regular expression tests can be applied to "string" values only.  The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).


to the member name from any JSON object in its input nodelist.  It selects no nodes from any other JSON value. <del> Note that the "dot-selector" follows the philosophy of JSON strings and is allowed to contain bit sequences that cannot encode Unicode characters (a single unpaired UTF-16 surrogate, for example).  The behaviour of an implementation is undefined for member names which do not encode Unicode characters. </del> 3.5.3. 3.5.3.1.

NAME It would be good to address NAME comments in this PR. I have made some suggestions, but feel free to pick them apart if you are keen to retain "truthiness" and "falsiness". BTW perhjaps I struggle with the latter term because of the existence of some .
Indeed. It is not that easy to say here what needs to be said, so I'm still in thinking mode. Thanks for the pointer to English slang; of course I was completely unaware. We don't want to use the fooiness terms. Interestingly, the remaining grammar does not seem to have a place where JSON values are implicitly converted to Boolean; this is now all explicit unless I'm missing something. So maybe we don't need this table (and its legend) at all?
You're right! The two occurrences of are as follows. which simply tests for non-existence of a value(s) selected by a path and does not depend on the actual values themselves. which negates a boolean expression. Looking at the details of , there's no way it can result in a value which might need to be converted to boolean. So please can we scrap the table and kiss "fooiness" goodbye once and for all?
I think we should first merge it and then delete it, in case we need to resurrect it later.
what's about ... which can surely be converted to a negated form. But sometimes someone doesn't want to do that ... like in any programming language. Nevertheless I second to kick fooiness out. As a minimalist I am always a friend of kicking unneeded things out.
Comparisons already yield Boolean values, as does /.
Well, then in fact I misunderstood Glyn's comment above ... I agree to remove the conversion table as superfluous.

to the member name from any JSON object in its input nodelist.  It selects no nodes from any other JSON value.  3.5.3. 3.5.3.1.


of their element or member values then.  Applied to other value types, it will select nothing. <del> : The zero number/empty string exceptions are no longer true. Booleans work the same everywhere. Negation operator "neg-op" allows to test of values. Applying negation operator twice "!!" gives us </del>  <del> of values. </del>  Some examples:

of their element or member values then.  Applied to other value types, it will select nothing.  <ins> DELETE-ME: (( We currently don't need this.  But we commit a version in case we do need it later.  The negation operator "neg-op" can be applied to any JSON value and returns "true" only when applied to "false" or "null": </ins>  <ins> Consequently, applying the negation operator twice "!!" returns "true" for all values except "false" or "null".  )) </ins> Some examples:


D.draft-bormann-jsonpath-iregexp for performance issues in regular expression implementations.)  Implementers need to be aware that good average performance is not sufficient as long as an attacker can <del> choose to submit specially crafted JSONPath queries that trigger surprisingly high, possibly exponential, CPU usage. </del>  5.2.

Also add some general advice from URL See also . Ref: URL
Recursion is not really the problem, stack depth is (or any other uncontrolled resource usage triggered by queries into deeply nested structures). Grüße, Carsten
NAME Are you comfortable with this now, or would you perhaps like to suggest some other way to address the concerns of URL
Thank you.Looks good and informative to me.

D.draft-bormann-jsonpath-iregexp for performance issues in regular expression implementations.)  Implementers need to be aware that good average performance is not sufficient as long as an attacker can  <ins> choose to submit specially crafted JSONPath queries or arguments that trigger surprisingly high, possibly exponential, CPU usage or, for example via a naive recursive implementation of the descendant selector, stack overflow.  Implementations need to have appropriate resource management to mitigate these attacks. </ins> 5.2.