unsigned CNAME records that may have been synthesized in the response from a DNS resolver. <del> The subsequent RRsets MUST contain the full sequence of DNS records needed to authenticate the TLSA record set from the server's trust anchor.  Typically this means a sequence of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone. </del>  Names that are aliased via CNAME and/or DNAME records may involve multiple branches of the DNS tree.  In this case, the authentication

Small tweak to text to make clearer that validation RRsets can be in any order.

unsigned CNAME records that may have been synthesized in the response from a DNS resolver.  <ins> The subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set from the server's trust anchor. Typically this means a set of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone.  The TLS client should be prepared to receive this set of RRsets in any order. </ins> Names that are aliased via CNAME and/or DNAME records may involve multiple branches of the DNS tree.  In this case, the authentication


for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by <del> the same entity. </del>  1.

changed equivalence instances for designated and added the possibility of multiple entities so long as they are cooperating This is to address issue
I am not sure we need to introduce "Equivalence" nor to develop who is operating the resolvers - especially as many entities may be involved in the operation of a resolver. I am not sure we need to introduce Equivalence. If so I would propose the following text: OLD: "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. NEW: "Equivalence" in this context means that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. If Equivalence is not introduced - which I prefer -I would propose the following text: NEW: In this context the discovery process ensures that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers.
I agree that we do not need to introduce "equivalence" in this document. It is a remnant of the DEER draft DDR is based on. Per WG discussion, we want to use the term "designation" to describe the relationship between the unencrypted resolver and the encrypted resolver to which the client is transferring. I'm editing accordingly. I have also added references to the possibility of multiple "entities" as that is definitely possible. (PR coming later tonight)
good.

for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by  <ins> the same entity or cooperating entities. </ins> 1.


Both of these approaches allow clients to confirm that a discovered Encrypted Resolver is designated by the originally provisioned <del> resolver.  "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. </del>  1.1.

Both of these approaches allow clients to confirm that a discovered Encrypted Resolver is designated by the originally provisioned  <ins> resolver.  "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. </ins> 1.1.


Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some form of certificate validation, new validation mechanisms will need <del> to be defined to support validating equivalence as defined in </del>  authenticated. 4.

Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some form of certificate validation, new validation mechanisms will need  <ins> to be defined to support validating designation as defined in </ins> authenticated. 4.


4.1.  In order to be considered an authenticated Designated Resolver, the <del> TLS certificate presented by the Encrypted Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </del>  designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the

Right now, we only allow authenticated and matching-IP opportunistic use of the DDR record. While use of the record in a case where authentication fails isn't safe to use automatically, we should clarify that implementations MAY choose to use the information anyhow by policy, and possibly with user control.
For authentication to matter, it generally has to operate without fallback. Currently the text is not very clear on this point, but it sure seems like IP-authenticated mode is expected to fall back to cleartext if no upgrade is possible. I think we need to clarify the use case for an authenticated mode, or abandon the distinction between opportunistic and authenticated. In my view, authenticated mode only makes sense if (1) the resolver is identified by its IP address AND (2) the system knows a priori that this resolver supports encrypted DNS, so that it can refuse to fall back to cleartext if the upgrade information is stripped by a network attacker. This is a sufficiently narrow use case that I lean toward dropping it entirely and recommending Discovery Using Resolver Names (Section 5) or opportunistic instead.
Currently, this is what we say (which I now see a grammatical error in, but there it is): We don't say anything else because that would be out of WG scope. The point of the document is to help a stub resolver configured with a recursive resolver known only by IP address to bootstrap into encrypted DNS. The stub resolver's posture on whether to fall back to unencrypted DNS or simply refuse to use the resolver is its own business. Look at this through a common OS scenario: the OS stub resolver learns an IP address from DHCP, and it's a public IP address (my old ISP did this). It knows of no other resolvers because the user doesn't know what DNS is and that's the default configuration (use network recommendation). If I try to use DDR and I get no answer back, then I'm in the same position as I was before DDR: I know of no other resolver, so I either have to use this one or have no DNS resolutions. DDR did not introduce that conundrum; it offers clients a way out of it when DNR is not present and there is no plain-text DNS attack present. The authenticated DDR mode allows such a client to be confident in the authenticity of the bootstrap even though it started over plain text. I do not agree this scenario is sufficiently narrow to drop. Is your concern over the usefulness of the scenario, or over naming it "authenticated"? I am open to suggestions on the latter; I strongly disagree with the former.
Both. How is this information useful to the client? I have not heard of any proposal for any client to behave differently on the basis of whether its encrypted connection is authenticated, when the resolver is identified by IP address. As for the name, RFC 7435 is the reference. I find it a bit confusing, but here's some of the relevant text: The "authenticated" section does not seem to describe an "authenticated" protocol by this definition, because it does not provide a downgrade-resistant method to determine that authentication is expected to work.
Please suggest a more accurate name then please. I do agree behavior naming should be consistent with other documents. Your bar for useful is apparently different from mine. Before DDR, a client configured only with an IP address had only unencrypted DNS as an option. With DDR, the client can possibly encrypt that connection. A transient attacker would have to have been present for the initial SVCB discovery to prevent that; an attacker arriving after DDR has taken place will be kept out of the loop. In the worst case, a client is returned to square one. I do not agree that just because a mechanism can be prevented means the mechanism provides no value. It doesn't have to. In the common case, the client is forced by lack of knowledge to use unencrypted DNS. If it can from that default configuration divine encrypted DNS configuration, that's a net positive. Resolver selection is out of scope and has nothing to do with it.
I've updated to address this question by reformulating the concept of authentication, and being much more explicit about the threat model. Yes, that's a good step, but it doesn't rely on authentication. This is a very helpful observation. I've incorporated it in .
I believe this particular issue is largely overtaken by events. Particularly, I think we've added some clarity and escape hatches with , and protections with .
Same comment for line 337/360 about referring to the resolver as Designated versus Encrypted (it's unmodified in this PR but based on your agreement with the other in-line comment it may need modified as well) I think we will need to add some text to the Security Considerations section to mention the security promise difference between following the MAY or not (for optional use of the unverifiable designation). However, we can close this PR without it and handle that in a new PR if that's preferable.

4.1. <ins> When a client discovers Designated Resolvers from an Unencrypted Resolver IP address, it can choose to use these Designated Resolvers either automatically, or based on some other policy, heuristic, or user choice. This document defines two preferred methods to automatically use Designated Resolvers: Authenticated Discovery authenticated, for when a TLS certificate can be used to validate the resolver's identity. Opportunistic Discovery opportunistic, for when a resolver is accessed using a non-public IP address. A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input.  Details of such policy are out of scope of this document.  Clients SHOULD NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. 4.2. Authenticated Discovery is a mechanism that allows automatic use of a Designated Resolver that supports DNS encryption that performs a TLS handshake. </ins> In order to be considered an authenticated Designated Resolver, the  <ins> TLS certificate presented by the Designated Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </ins> designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the


Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does <del> not cover the Unencrypted Resolver address, the client MUST NOT use the discovered Encrypted Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </del>  If the Designated Resolver and the Unencrypted Resolver share an IP <del> address, clients MAY choose to opportunistically use the Encrypted </del>  Resolver even without this certificate check (opportunistic). <del> If resolving the name of an Encrypted Resolver from an SVCB record </del>  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 <del> and validated IP address for the same Encrypted Resolver name. </del>  <del> 4.2. </del>  There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes

Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does  <ins> not cover the Unencrypted Resolver address, the client MUST NOT automatically use the discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </ins> If the Designated Resolver and the Unencrypted Resolver share an IP  <ins> address, clients MAY choose to opportunistically use the Designated </ins> Resolver even without this certificate check (opportunistic).  <ins> If resolving the name of a Designated Resolver from an SVCB record </ins> 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  <ins> and validated IP address for the same Designated Resolver name. </ins>  <ins> 4.3. </ins> There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes


like RA guard RFC6105.  An attacker might try to direct Encrypted DNS traffic to itself by causing the client to think that a discovered Designated Resolver uses a different IP address from the Unencrypted <del> Resolver.  Such an Encrypted Resolver might have a valid certificate, </del>  but be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network. <del> If the IP address of a Designated Resolver differs from that of an Unencrypted Resolver, clients MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Encrypted Resolver's TLS certificate (authenticated). </del>  <del> Opportunistic use of Encrypted Resolvers MUST be limited to cases where the Unencrypted Resolver and Designated Resolver have the same IP address (opportunistic). </del>  8.

like RA guard RFC6105.  An attacker might try to direct Encrypted DNS traffic to itself by causing the client to think that a discovered Designated Resolver uses a different IP address from the Unencrypted  <ins> Resolver.  Such a Designated Resolver might have a valid certificate, </ins> but be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network.  <ins> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this documents, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </ins>  <ins> If the IP address of a Designated Resolver differs from that of an Unencrypted Resolver, clients applying Authenicated Discovery (authenticated) MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Designated Resolver's TLS certificate. Clients using Opportunistic Discovery (opportunistic) MUST be limited to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. </ins> 8.


resolvers frequently support a local "hosts file" that preempts query forwarding, and most DNS forwarders and full resolvers can also serve responses from a local zone file.  Other standardized hybrid <del> resolution behaviors include Local Root RFC8806, mDNS RFC6762, and NXDOMAIN synthesis for .onion RFC7686. </del>  In many network environments, the network offers clients a DNS server (e.g.  DHCP OFFER, IPv6 Router Advertisement).  Although this server

Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.

resolvers frequently support a local "hosts file" that preempts query forwarding, and most DNS forwarders and full resolvers can also serve responses from a local zone file.  Other standardized hybrid  <ins> resolution behaviors include RFC8806, RFC6762, and RFC7686. </ins> In many network environments, the network offers clients a DNS server (e.g.  DHCP OFFER, IPv6 Router Advertisement).  Although this server


3. <del> The protocol in this document allows the domain owner to create a split-horizon DNS.  Other entities which do not own the domain are detected by the client.  Thus, DNS filtering is not enabled by this </del>  protocol. 4.

3.  <ins> The protocol in this document is designed to support the ability of a domain owner to create or authorize a split-horizon view of their domain.  The protocol does not support split-horizon views created by any other entity.  Thus, DNS filtering is not enabled by this </ins> protocol. 4.


4.1. There are several DHCP options that convey local domain hints of <del> different kinds.  The most directly relevant is "RDNSS Selection" RFC6731, which provides "a list of domains ... about which the RDNSS has special knowledge", along with a "High", "Medium", or "Low" preference for each name.  The specification notes the difficulty of relying on these hints without validation: Other local domain hints in DHCP include the "Domain Name" RFC2132, "Access Network Domain Name" RFC5986, "Client FQDN" RFC4704, and "Name Service Search" RFC2937 options.  This specification may help clients to interpret these hints.  For example, a rogue DHCP server could use the "Client FQDN" option to assign a client the name </del>  "www.example.com" in order to prevent the client from reaching the true "www.example.com".  A client could use this specification to check the network's authority over this name, and adjust its behavior

4.1. There are several DHCP options that convey local domain hints of  <ins> different kinds.  The most directly relevant is RFC6731, which provides "a list of domains ... about which the RDNSS has special knowledge", along with a "High", "Medium", or "Low" preference for each name.  The specification notes the difficulty of relying on these hints without validation: Other local domain hints in DHCP include the RFC2132, RFC5986, "Client FQDN" RFC4704, and RFC2937 options.  This specification may help clients to interpret these hints.  For example, a rogue DHCP server could use the "Client FQDN" option to assign a client the name </ins> "www.example.com" in order to prevent the client from reaching the true "www.example.com".  A client could use this specification to check the network's authority over this name, and adjust its behavior


SSID, IP subnet assigned, DNS server IP address or name, and other similar mechanisms.  For example, one existing implementation determines the host has joined an internal network because the DHCP- <del> assigned IP address belongs to the company's IP address (as assigned by the regional IP addressing authority) and the DHCP-advertised DNS IP address is one used by IT at that network.  Other mechanisms exist in other products but are not interesting to this specification; rather what is interesting is this step to determine "we have joined the internal corporate network" occurred and the DNS server is configured as authoritative for certain DNS zones (e.g., *.example.com). </del>  Because a rogue network can simulate all or most of the above <del> characteristics this specification details how to validate these </del>  claims in validating. 4.3.

SSID, IP subnet assigned, DNS server IP address or name, and other similar mechanisms.  For example, one existing implementation determines the host has joined an internal network because the DHCP-  <ins> assigned IP address belongs to the company's IP range (as assigned by the regional IP addressing authority) and the DHCP-advertised DNS IP address is one used by IT at that network.  Other mechanisms exist in other products but are not interesting to this specification; rather what is interesting is this step to determine "we have joined the internal corporate network" occurred and the DNS server is configured as authoritative for certain DNS zones (e.g., ). </ins> Because a rogue network can simulate all or most of the above  <ins> characteristics, this specification details how to validate these </ins> claims in validating. 4.3.


7. <del> Two examples are shown below.  The first example showing an company with an internal-only DNS server resolving the entire zone for that company (e.g., *.example.com) the second example resolving only a subdomain of the company's zone (e.g., *.internal.example.com). </del>  7.1.

7.  <ins> Two examples are shown below.  The first example shows a company with an internal-only DNS server that claims the entire zone for that company (e.g., ).  In the second example, the internal servers resolves only a subdomain of the company's zone (e.g., ). </ins> 7.1.


Today, on the Internet it publishes two NS records, "ns1.example.com" and "ns2.example.com". <del> The host and network first need mutual support one of the mechanisms described in learning.  Shown in fig-learn is learning using DNR and PvD. </del>  <del> Validation is then perfomed using either example-verify-public or </del>  example-verify-dnssec. 7.1.1. The figure below shows the steps performed to verify the local claims <del> of DNS authority using a public resolver. </del>  7.1.2.

Today, on the Internet it publishes two NS records, "ns1.example.com" and "ns2.example.com".  <ins> First, the host and network both need to support one of the discovery mechanisms described in learning. fig-learn shows discovery using DNR and PvD. </ins>  <ins> Validation is then perfomed using either example-verify-external or </ins> example-verify-dnssec. 7.1.1. The figure below shows the steps performed to verify the local claims  <ins> of DNS authority using an external resolver. </ins> 7.1.2.


7.2. <del> A subdomain can also be used for all internal DNS names (e.g., the zone internal.example.com exists only on the internal DNS server). For successful validation described in this document the the internal DNS server will need a certificate signed by a CA trusted by the client. </del>  <del> For such a name internal.example.com the message flow is similar to internal-only the difference is that queries for hosts not within the subdomain (www.example.com) are sent to the public resolver rather than resolver for internal.example.com. </del>  8.

7.2.  <ins> In many split-horizon deployments, all non-public domain names are placed in a separate child zone (e.g., ).  In this configuration, the message flow is similar to internal- only, except that queries for hosts not within the subdomain (e.g., </ins>  <ins> ) are sent to the external resolver rather than resolver for internal.example.com. As in internal-only, the internal DNS server will need a certificate signed by a CA trusted by the client. </ins> 8.


ensure that names under the split-horizon are correctly signed or place them in an unsigned zone. <del> If an internal zone name (e.g., internal.example.com) is used with this specification and a public certificate is obtained for validation, that internal zone name will exist in Certificate Transparency logs RFC9162.  It should be noted, however, that this specification does not leak individual host names (e.g., www.internal.example.com) into the Certificate Transparancy logs or to public DNS resolvers. </del>  10.

ensure that names under the split-horizon are correctly signed or place them in an unsigned zone.  <ins> If an internal zone name (e.g., ) is used with this specification and a public certificate is obtained for validation, that internal zone name will exist in Certificate Transparency logs RFC9162.  It should be noted, however, that this specification does not leak individual host names (e.g., ) into the Certificate Transparency logs or to external DNS resolvers. </ins> 10.


3. <del> Names are formed using Port-Prefix Naming (Section 2.3 of SVCB), with a scheme of "dns".  For example, SVCB records for a DNS service identified as ""dns1.example.com"" would be located at ""_dns.dns1.example.com"". </del>  3.1.

This should help with the case in DDR. See URL
Much better. Thanks for indulging me.

3.  <ins> SVCB record names (i.e.  QNAMEs) are formed using Port-Prefix Naming (Section 2.3 of SVCB), with a scheme of "dns".  For example, SVCB records for a DNS service identified as ""dns1.example.com"" would be queried at ""_dns.dns1.example.com"". In some use cases, the name used for retrieving these DNS records is different from the server identity used to authenticate the secure transport.  To distinguish them, we use the following terms: Binding authority - The service name (Section 1.4 of SVCB) and optional port number used as input to Port-Prefix Naming. Authentication name - The name used for secure transport authentication.  It must be a DNS hostname or a literal IP address.  Unless otherwise specified, it is the service name from the binding authority. </ins> 3.1.


default of 53).  DNS URIs normally omit the authority, or specify an IP address, but a hostname and non-default port number are allowed. <del> When a non-default port number is part of a service identifier, Port- </del>  Prefix Naming places the port number in an additional a prefix on the <del> name.  For example, SVCB records for a DNS service identified as ""dns1.example.com:9953"" would be located at </del>  ""_9953._dns.dns1.example.com"".  If two DNS services operating on different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative

default of 53).  DNS URIs normally omit the authority, or specify an IP address, but a hostname and non-default port number are allowed.  <ins> When the binding authority specifies a non-default port number, Port- </ins> Prefix Naming places the port number in an additional a prefix on the  <ins> name.  For example, if the binding authority is ""dns1.example.com:9953"", the client would query for SVCB records at </ins> ""_9953._dns.dns1.example.com"".  If two DNS services operating on different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative


presentation and wire format) is a relative URI Template RFC6570, normally starting with "/".  If the "alpn" SvcParamKey indicates support for HTTP, clients MAY construct a DNS over HTTPS URI Template <del> by combining the prefix "https://", the service name, the port from the "port" key if present, and the "dohpath" value.  (The DNS service's original port number MUST NOT be used.) </del>  Clients SHOULD NOT query for any "HTTPS" RRs when using the constructed URI Template.  Instead, the SvcParams and address records

presentation and wire format) is a relative URI Template RFC6570, normally starting with "/".  If the "alpn" SvcParamKey indicates support for HTTP, clients MAY construct a DNS over HTTPS URI Template  <ins> by combining the prefix "https://", the authentication name, the port from the "port" key if present, and the "dohpath" value.  (The binding authority's port number MUST NOT be used.) </ins> Clients SHOULD NOT query for any "HTTPS" RRs when using the constructed URI Template.  Instead, the SvcParams and address records


This section considers an adversary who can add or remove responses to the SVCB query. <del> Clients MUST authenticate the server to its name during secure transport establishment.  This name is the hostname used to construct the original SVCB query, and cannot be influenced by the SVCB record contents.  Accordingly, this draft does not mandate the use of DNSSEC.  This draft also does not specify how clients authenticate the name (e.g. selection of roots of trust), which might vary according to the context. </del>  Although this adversary cannot alter the authentication name of the service, it does have control of the port number and "dohpath" value.

This section considers an adversary who can add or remove responses to the SVCB query.  <ins> During secure transport establishment, clients MUST authenticate the server to its authentication name, which is not influenced by the SVCB record contents.  Accordingly, this draft does not mandate the use of DNSSEC.  This draft also does not specify how clients authenticate the name (e.g. selection of roots of trust), which might vary according to the context. </ins> Although this adversary cannot alter the authentication name of the service, it does have control of the port number and "dohpath" value.


the delegation, even though they are not themselves authoritative data.  "[Resource records] which are not part of the authoritative data [of the zone], and are address resource records for the [name servers in subzones].  These RRs are only necessary if the name

We don't seem to have defined "lame delegation", which is a term that is used all the time. It's in RFC 1912. Should we add it?
Yes.

the delegation, even though they are not themselves authoritative data. <ins> "A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually because it is not set up as a primary or secondary for the zone)." (Definition from RFC1912, Section 2.8) </ins> "[Resource records] which are not part of the authoritative data [of the zone], and are address resource records for the [name servers in subzones].  These RRs are only necessary if the name


An instruction is a Service Discovery Instruction if it contains  2.3.1.2. An instruction is a Service Description Instruction if, for the

Update Service Discovery Instruction text to address Esko Dijk's last call comments. This fixes a bogus reference, removes a confusing double negative, and splits the text hierarchically in a way that hopefully makes more sense.

An instruction is a Service Discovery Instruction if it contains <ins> Note that there can be more than one Service Discovery Instruction for the same name if the SRP requestor is advertising more than one service of the same type, or is changing the target of a PTR RR.  For each such PTR RR add or remove, the above constraints must be met. </ins> 2.3.1.2. An instruction is a Service Description Instruction if, for the


The protocol must permit the addition of new formats for DNS queries and responses. <del> The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to contain future modifications to the DNS protocol including the inclusion of one or more EDNS extensions (including those not yet defined). </del>  The protocol must use a secure transport that meets the requirements for HTTPS.

This text does not read very well in its current form. Since it is two ideas, two sentences is best.

The protocol must permit the addition of new formats for DNS queries and responses.  <ins> The protocol must ensure interoperability by specifying a single format for requests and responses that is mandatory to implement. That format must be able to support future modifications to the DNS protocol including the inclusion of one or more EDNS extensions (including those not yet defined). </ins> The protocol must use a secure transport that meets the requirements for HTTPS.


A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different <del> DNS retrieval mechanism, doing so can weaken the privacy expected by the user of the client. </del>  9.

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

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  <ins> DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client. </ins> 9.


to achieve similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very <del> poor performance for many uses cases. </del>  6.3.

Hello, I am a non-native English speaker but I noticed the following sentence: "Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very poor performance for many uses cases." Shouldn't be there at the end? Wiktionary ( URL ) suggests that plural of "use case" is "use cases", not "uses cases".

to achieve similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very  <ins> poor performance. </ins> 6.3.


The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client <del> MUST be prepared to process "message/dns" (as described in dnswire) responses but MAY also process any other type it receives. </del>  In order to maximize cache friendliness, DNS API clients using media <del> formats that include DNS ID, such as message/dns, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as message/ dns.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </del>  DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.

Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.

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


"https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records. <del> The requests are represented as message/dns typed bodies. </del>  The first example request uses GET to request www.example.com

"https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records.  <ins> The requests are represented as application/dns-message typed bodies. </ins> The first example request uses GET to request www.example.com


At the time this is published, the response types are works in progress.  The only response type defined in this document is <del> "message/dns", but it is possible that other response formats will be defined in the future. </del>  <del> The DNS response for "message/dns" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </del>  Each DNS request-response pair is matched to one HTTP exchange.  The responses may be processed and transported in any order using HTTP's

At the time this is published, the response types are works in progress.  The only response type defined in this document is  <ins> "application/dns-message", but it is possible that other response formats will be defined in the future. </ins>  <ins> The DNS response for "application/dns-message" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP exchange.  The responses may be processed and transported in any order using HTTP's


caching discusses the relationship between DNS and HTTP response caching. <del> A DNS API server MUST be able to process message/dns request messages. </del>  A DNS API server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to

caching discusses the relationship between DNS and HTTP response caching.  <ins> A DNS API server MUST be able to process application/dns-message request messages. </ins> A DNS API server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to


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

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


DNS API clients using the DNS wire format MAY have one or more EDNS options RFC6891 in the request. <del> The media type is "message/dns". </del>  7.

DNS API clients using the DNS wire format MAY have one or more EDNS options RFC6891 in the request.  <ins> The media type is "application/dns-message". </ins> 7.


<del> DNS Queries over HTTPS </del>  draft-ietf-doh-dns-over-https Abstract <del> This document describes how to run DNS service over HTTP (DOH) using https:// URIs. </del>  1. This document defines a specific protocol for sending DNS RFC1035 <del> queries and getting DNS responses over HTTP RFC7540 using https:// </del>  (and therefore TLS RFC5246 security for integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP exchange.

The "using https:// URIs" part is just odd. Easier to simply state that this uses HTTPS at this level. Also, if the concept of a DNS service evolves to encompass other types of exchange than simple request-response, then "run DNS service" won't be accurate.
I added "DOH" to the title because it was now being removed from the Abstract.

<ins> DNS Queries over HTTPS (DOH) </ins> draft-ietf-doh-dns-over-https Abstract  <ins> This document describes how to make DNS queries over HTTPS. </ins> 1. This document defines a specific protocol for sending DNS RFC1035  <ins> queries and getting DNS responses over HTTP RFC7540 using https URIs </ins> (and therefore TLS RFC5246 security for integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP exchange.


5.3. Before using DOH response data for DNS resolution, the client MUST <del> establish that the HTTP request URI is a trusted service for the DOH query.  For HTTP requests initiated by the DNS API client this trust </del>  is implicit in the selection of URI.  For HTTP server push (RFC7540 Section 8.2) extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request.  This specification does not extend DNS resolution privileges to URIs that are not recognized by the <del> client as trusted DNS API servers. </del>  5.4.

This is OK, but I like the changes in better because it brings the "trust" discussion further forwards. Preferences?
I prefer this PR over - changing from trust to authorization is more on point
I agree authorize is closer to the correct concept here but I'd like to see a definition of it (in a section of it's own early in the document). But - I don't believe there is an existing concept in DNS or DNSSEC that this is re-using? Does 'authorize' here mean that: the client will use all response from that server for resolution the client will cache all responses received from that server Also, if the trusted resolver itself isn't doing DNSSEC validation then the client's cache can still be poisoned. The only 100% sure method to stop cache poisoning is for the caching entity to perform DNSSEC validation.

5.3. Before using DOH response data for DNS resolution, the client MUST  <ins> establish that the HTTP request URI is authorized for the DOH query. For HTTP requests initiated by the DNS API client this authorization </ins> is implicit in the selection of URI.  For HTTP server push (RFC7540 Section 8.2) extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request.  This specification does not extend DNS resolution privileges to URIs that are not recognized by the  <ins> client as authorized DNS API servers. </ins> 5.4.


security implications of HTTP caching for other protocols that use HTTP. <del> A server that is acting both as a normal web server and a DNS API server is in a position to choose which DNS names it forces a client to resolve (through its web service) and also be the one to answer those queries (through its DNS API service).  An untrusted DNS API server can thus easily cause damage by poisoning a client's cache with names that the DNS API server chooses to poison.  A client MUST NOT trust a DNS API server simply because it was discovered, or because the client was told to trust the DNS API server by an untrusted party.  Instead, a client MUST only trust DNS API server that is configured as trustworthy. </del>  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

security implications of HTTP caching for other protocols that use HTTP.  <ins> In the absence of information about the authenticity of responses, such as DNSSEC, a DNS API server can poison a client's cache.  A client MUST NOT authorize arbitrary DNS API servers.  Instead, a client MUST specifically authorize DNS API servers using mechanisms such as explicit configuration. </ins> A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP


partially because they did not follow HTTP best practices. This document defines a specific protocol for sending DNS RFC1035 <del> queries and getting DNS responses over modern versions of HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP request-response pair. </del>  The described approach is more than a tunnel over HTTP.  It establishes default media formatting types for requests and responses

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

partially because they did not follow HTTP best practices. This document defines a specific protocol for sending DNS RFC1035  <ins> queries and getting DNS responses over HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP request-response pair. </ins> The described approach is more than a tunnel over HTTP.  It establishes default media formatting types for requests and responses


This protocol MUST be used with https scheme URI RFC7230. <del> 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. </del>  8.

This protocol MUST be used with https scheme URI RFC7230.  <ins> 7.1. The minimum version of HTTP used by DOH SHOULD be HTTP/2 RFC7540. The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs 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 conveying the semantic requirements of DOH but would result in very poor performance for many uses cases. </ins> 8.


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

9. Running DNS over HTTPS relies on the security of the underlying HTTP  <ins> transport.  Implementations utilizing HTTP/2 benefit from the TLS profile defined in RFC7540 Section 9.2. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with


but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are expected to make this protocol function in some environments where <del> DNS directly on TLS (RFC7858) would not. </del>  A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done

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.

but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are expected to make this protocol function in some environments where  <ins> unsecured DNS (DNS) or DNS directly on TLS (RFC7858) would not. </ins> A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done


conveying the semantic requirements of DOH but may result in very poor performance for many uses cases.  8. 8.1.

Describe how GET (not POST) is used with server push. This will ensure that you answer the bigger question: what do you do with a server push from an arbitrary server? I assume that this won't be privileged in any way, and only the configured DNS API server will have its answers routed to the DNS stack, but that needs to be explicit.
Server push in a request-response protocol like DNS would take a lot of designing. It isn't really needed in DNS because the server can always slap in additional answers in the Additional section of a request. I propose we close this by saying "HTTP server push is not defined for this protocol, but might be defined in a future version". If someone wants to define an EDNS0 or session-signal extension for it, that should be just fine.
HTTP already has server push, so I would prefer something closer to "this protocol does not alter the semantics of HTTP server push".
I think NAME is closer to what I'm thinking.. (though I don't really think that needs to be stated beyond other clarifications that this document just uses http in a particular manner, it does not define it.) additionally RR's don't quite address the same use case by the way as push can operate in more of a pub-sub fashion if you like where an additional RR is definitely a poll model.
Of course this protocol does not alter the semantics of server push, but what does it mean for a DNS client? In the DNS protocol, the only thing even vaguely like server-initiated information is stuff in the Additional section of an answer, and even then, there are pretty strict rules about ignoring it if it is at all smelly.
an often times misunderstood part of push is that a server pushes both a response and the request that it is responding to. (like dns, http is always a request/response pair, so if the client doesn't provide the request the server needs to). So that's what it means - its an answer to a particular question and you can cache it or not depending on whether that's a request you would have asked/trusted the peer to handle. That's pretty much the same rule for dns and traditional http clients. A client who would rather not have things pushed at them has existing protocol mechanisms to disable that (SETTINGS) which doh doesn't need to specify. I think all of this gets at what NAME was originally commenting on - you need to make a decision on whether or not you trust the server for the query/response being pushed (i.e is this your dns api server otherwise don't accept) before processing it.. this is already true for anything pushed via http but a sentence making it explicit is fine.

conveying the semantic requirements of DOH but may result in very poor performance for many uses cases. <ins> 7.3. Before using DOH response data for DNS resolution, the client MUST establish that the HTTP request URI is a trusted service for the DOH query.  For HTTP requests initiated by the DNS API client this trust is implicit in the selection of URI.  For HTTP server push (RFC7540 Section 8.2) extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request.  This specification does not extend DNS resolution privileges to URIs that are not recognized by the client as trusted DNS API servers. </ins> 8. 8.1.


using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). <del> All other parameters such as MSK and EMSK are derived in the same manner as with EAP-TLS RFC5216, Section 2.3.  The definitions are repeated below for simplicity: </del>  The use of these keys is specific to the lower layer, as described RFC5247.

Proposal to change the derivation of the EMSK and MSK individually and directly from TLS exporter. Defines new tags for this purpose.
Thanks!

using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446).  <ins> All other parameters are derived in the same manner as with EAP-TLS RFC5216, Section 2.3.  The definitions are repeated below for simplicity: </ins> The use of these keys is specific to the lower layer, as described RFC5247.


The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NewSessionTicket message MUST NOT include an "early_data" extension. <del> A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I-D.ietf-tls- ticketrequests. </del>  figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a

According to suggeestion in issue
Alan has suggested that more Profiling / guidance regarding NewSessionTicket would be good. TLS 1.3 allows any number of newsessionticket to be send in any of the server flights. All ways are secure. TLS 1.3 leaves how and when to the TLS implementation.
This is a new request for technical change not related to the IESG DISUCUSS. Based on earlier discussions changes to the TLS layer are likely a bit controversial. John: I don't see what is special with EAP-TLS here. I also don't know what a good recommendation for the TLS layer would be or what can be enforced in TLS implementations. This would likely need interaction with TLS people,
Note also that draft-ietf-tls-ticketrequests is in the RFC Editor's queue and goes into a bit more detail about when different numbers of tickets might be desired (as well as a mechanism to indicate the client's desires, though it's not entirely clear to me whether that will be very helpful for the EAP-TLS usage).
Based on your earlier comment on draft-ietf-tls-ticketrequests, I already added a reference to ietf-tls-ticketrequests in version -14 "A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in [I-D.ietf-tls-ticketrequests]."
Oops, shame on me for not checking. (Thanks for adding the reference the last time I mentioned it!)
I think it would be fine to include a SHOULD send only one NewSessionTicket since EAP clients will typically only need one at a time.
I am not comfortable adding such guidance without a thorough survey of libraries. As draft-ietf-tls-ticketrequests says: "servers vend some (often hard-coded) number of tickets per connection. Some server implementations return a different default number of tickets for session resumption than for the initial connection that created the session. No static choice, whether fixed, or resumption-dependent is ideal for all situations." I know that openssl allows to control number of tickets with URL but I don't we think we can be sure about behavior of all libraries out there. Also some noteworthy text from draft-ietf-tls-ticketrequests: "Especially when the client was initially authenticated with a client certificate, that session may need to be refreshed from time to time. Consequently, a server may periodically force a new connection even when the client presents a valid ticket. When that happens, it is possible that any other tickets derived from the same original session are equally invalid. A client avoids a full handshake on subsequent connections if it replaces all stored tickets with new ones obtained from the just performed full handshake. The number of tickets the server should vend for a new connection may therefore need to be larger than the number for routine resumption."
How about removing the normative SHOULD, something like: desired number of tickets needed for future connections is defined in [I-D.ietf-tls-ticketrequests]. >
This non-normative suggestion sounds good to me.
John's suggested text looks good. By the way, I checked boringssl: URL It seems to issue 2 tickets by default (static const int kNumTickets = 2). As far as I can tell, the only way to limit to 1 ticket is by changing the code manually and re-compiling the library.
This is resolved in PR
Merged PR

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


order things are sent and the application data MAY therefore be sent before a NewSessionTicket.  TLS application data 0x00 is therefore to be interpreted as success after the EAP-Request that contains TLS <del> application data 0x00.  After the EAP-TLS server has received an empty EAP-Response to the EAP-Request containing the TLS application data 0x00, the EAP-TLS server sends EAP-Success. </del>  figbase1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest

URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".

order things are sent and the application data MAY therefore be sent before a NewSessionTicket.  TLS application data 0x00 is therefore to be interpreted as success after the EAP-Request that contains TLS  <ins> application data 0x00.  After the EAP-TLS server has sent an EAP- Request containing the TLS application data 0x00 and received an EAP- Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server sends EAP-Success. </ins> figbase1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest


"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode is also important in order to limit the impact of a key compromise. When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning <del> that key leakage does not compromise any earlier connections.  It is RECOMMMENDED to use "psk_dhe_ke" for resumption. </del>  2.1.4.

"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode is also important in order to limit the impact of a key compromise. When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning  <ins> that key leakage does not compromise any earlier connections.  The "psk_dh_ke" mechanism MUST be used for resumption unless the deployment has a local requirement to allow configuration of other mechanisms. </ins> 2.1.4.


figterm3 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer <del> fails to authenticate to the EAP-TLS server and sends a TLS Error alert. </del>  2.1.5.

figterm3 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer  <ins> fails to authenticate to the EAP-TLS server and the server sends a TLS Error alert. </ins> 2.1.5.


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

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


3.6.  A Normalized Path is a JSONPath with restricted syntax that identifies a node by providing a query that results in exactly that node.  For example, the JSONPath expression "$.book[?(@.price<10)]"

Fixes URL
From it was stated that the current ABNF doesn't require parentheses around the expression in a filter expression. The spec thus contains examples without them. Previous discussions had occurred around making them optional, but no decision came out of them that I can recall. The closest documented conversation I could find was by NAME and the following comments which indicate that the parentheses are currently expected. To be clear, we should currently require , and disallow . The original blog post consistently uses them and never shows a filter expression selector without them.
I don't have a strong opinion on this simplification, but one data point: The simplified grammar has been in the document since we added ABNF grammar, i.e., in draft-ietf-jsonpath-base-01 (2021-07-08). The discussion was started in , 2021-04-30. For me, the current ABNF is the status quo.. If we need to have a discussion here, let's have it, but I'm not interested in the "we haven't discussed this enough" angle -- this has been out in the document for 9 months. So if there are any technical arguments for requiring the parentheses, please add them here.
I am strongly voting for the simplified, backwards compatible notation with optional parentheses.
The PR that put in the ABNF (which has never changed in substance with regard to requiring parentheses): URL There is even a comment from you (Greg) on that ABNF snippet in that PR conversation, so you apparently reviewed it. (Of course, you might have missed the simplification and there may be technical arguments against it -- let's hear them.)
Yes, looking back, I see point 4.1 in raised the topic, and the fact that it wasn't discussed at all (even though the original post said it should be discussed) could have been interpreted as acceptance and agreement. Also, that PR you reference is massive. It's easy to miss in the multitude of changes contained therein. I suspect this was something that was snuck in rather than agreed upon. Agreement requires discussion, and I see none. Personally, when I see , the looks as though it's part of the expression. Having the parentheses, , better isolates the expression visually. This is not a problem of parsing, but one of the human element.
For the record, I was originally uncomfortable with the parentheses being optional, but I remember this being discussed at a meeting quite a while ago and I was persuaded at that time that the current approach is reasonable. Perhaps that discussion wasn't highlighted in the minutes. I think we should stay as we are.
NAME I know you already commented to the contrary, but your original post has this to say: I think this is pretty indicative that parentheses should be included as part of the required syntax. Taking this stance also aligns with our preference to accommodate existing implementations. While we say that this is a backward compatible change, it may not be. For instance, my parser won't recognize a filter selector without the parentheses. I expect many other existing implementations will be the same.
At today's meeting I took an action to write a comparison project test for a filter without parentheses. It turns out there is one already -- URL -- and the consensus among implementations is "Not supported".
Hardly indicative. Original Goessner JsonPath used JavaScript for evaluating filter expressions, I imagine that requiring the outer parentheses was just to provide a pragmatic way to delimit the JavaScript part, original Goessner JsonPath was not responsible for parsing that part. That consideration no longer applies when the syntax of filter expressions is defined in the JSONPath specification, mandatory outer parentheses no longer serve any purpose. Be real :-) The spec in its current form is incompatible to a lessor or greater extent with all existing JSONPath implementations.
I still vote for the lean syntax with optional parentheses in filter expressions. Old queries (having parentheses) can be handled by 'old' and 'new' implementations without problems (backward compatibility). We don't break old 'query code'. New queries (no parentheses) can be treated by 'new' implementations only. This is the same behavior compared with regular expressions in filters, not being understood by old implementations. Thanks for Daniel also making that point. Am 26.04.2022 um 19:26 schrieb Daniel Parker:
My issue isn't that existing paths can be handled by new implementations (what we're calling "backward comparability"), but rather the inverse: new paths won't be handled by existing implementations ("forward compatibility"). Users will complain that their paths, which don't have parentheses, don't work. Implementors will respond with, "You need parentheses," and then users will be trained to use parentheses anyway. As it stands, most users are already trained to use parentheses because existing implementations require them.
Right. For new features we can't expect forward compatibility anyway. The discussion here was whether it is worth to reduce forward compatibility by admitting new syntax for existing, widely implemented features. And I grudgingly have to acknowledge that that is a different question. Actually, implementers will quickly fix that. Between competing implementations, there is a race to accept the largest amount of inputs (within reason, i.e., balancing it with the cost of implementing them). But, yes, query creators that care about widest compatibility will be trained to use the parentheses. (For me, actually, having a feature that only new implementations can understand is a feature. So the expression will break on implementations that haven't been updated. Darwin. And a nice canary.) Yes, which is part of the reason why I still think we would better give up on forward compatibility here in favor of cleaning up the query language. But that is now a matter of taste, and I have to accept that there is a valid argument to the contrary.
I just don't think it makes sense to go down this road. Users will understand that IETF JsonPath is just another take on the idea of JSONPath, an idea that took major forks from very early on. Any Stack Overflow question on JSONPath quickly establishes that the answers are generally implementation specific.
I'm going to stop pushing this, but I would like to add this last comment. JSON Schema has had several forward-incompatible changes over the years as well that I've been fine with. But the difference between this and those is that JSON Schema is already published and versioned. It's easy to tell people, "As of version X, this feature works differently." We're not technically versioned as yet because we don't really have a proper publication from which a full implementation can be built (because we're not done). It feels different to make this change for a 1.0. But I'll follow the team's consensus.
Have you submitted an issue?
No. I would add that the fact that they're different doesn't mean that they're wrong, because languages like Python, JavaScript and C use different precedence orderings, particularly Python and JavaScript, see e.g. and , , and . My comment to NAME was only about them being different.
NAME please do; I wasn't aware they are different. (Thanks for the pointers, very useful! -- the C one is a copy of the XPath one, though, and I can't resolve the Python one.)
All right, .
I'm not sure what the big fuss about the precedences being different is. For the operations we have defined, all of these are largely equivalent. Some have variation in that comparisons are higher than equality, but I'm not even sure under what circumstances that'd be useful. Contrivingly, I could say as a shorthand for but that's stretching things, IMO. I can't see that such a thing would be so useful that they'd add it into the language. NAME do you know why that split in precedence is defined?
NAME My own, personal view, is that it's unrewarding to think about precedences, and uninteresting to spend any time at all on thinking about the implications of trying something different. That's why my personal preference is to blindly follow what somebody else has already done, and not attempt anything new. I'd like to assume that the authors of C and Python have thought about this, I don't want to. So, when I implemented this, I followed C, except where C didn't have , I followed Perl, and ended up with . If like NAME I had a strong preference that the comparison and equality operators belonged at the same level, I would have chosen another language to follow that did that, Python qualifies, and used that language as a model for all operators, except , which Python doesn't have, and gone with Perl again for that. What I wouldn't do is is help myself to Python's comparison and equality operators, but C's logical not operator. As much as possible, I would want one model to base my implementation on. Daniel
very helpfull indeed. IIRC ... I took my first proposal of the precedence table from JavaScript (MDN), which should follow C. So I cannot explain the fact now, why has the same precedence as . Maybe we also should follow C ... and also include an associativity column. oh, and insert following Perl. thanks
Why is there a difference? I don't see how the precedence chain we've declared is any different than any of these languages. They're semantically identical! groups not comparison/equality (what benefit is there to separating these?) logical and logical or All of the listed languages have this ordering. What is being discussed here?
The current spec is silent about how is handled in many situations: What is the result of applying the JSONPath to the JSON document ? What is the result of applying the JSONPath to the JSON document ? The implies a node set with the single value . What is the result of applying the JSONPath to the JSON document ? The implies a node set with the single value . What is the result of applying the JSONPath to the JSON document ? Presumably a node set with the single value . What is the result of applying the JSONPath to the JSON document ? Presumably a node set with the values and . What is the result of applying the JSONPath to the JSON document ? What is the result of applying the JSONPath to the JSON document ? What is the result of applying the JSONPath to the JSON document ? The implies a node set with the single value .
To 1.: Similar is URL To 6.: URL To 7.: URL
I have historically handles as a valid value (contrary to most of .net) separate from "undefined" or "missing." As a result, I agree with these points. Specifically for [7], this is an existence test. Since exists as a property in the object, that object would be returned. I believe we decided that existence testing does not consider falsiness.

3.6. <ins> Note that JSON "null" is treated the same as any other JSON value: it is not taken to mean "undefined" or "missing". 3.6.1. JSON document: Queries: 3.7. </ins> A Normalized Path is a JSONPath with restricted syntax that identifies a node by providing a query that results in exactly that node.  For example, the JSONPath expression "$.book[?(@.price<10)]"


only if that object has a member with that name.  Nothing is selected from a value that is not a object. <del> Array indexing via "element-index" is a way of selecting a particular array element using a zero-based index.  For example, selector "[0]" selects the first and selector "[4]" the fifth element of a sufficiently long array. </del>  A negative "element-index" counts from the array end.  For example, selector "[-1]" selects the last and selector "[-2]" selects the

The index selector (but not the index wildcard selector) selects no elements from non-arrays. See URL for background.
This seems implicit since JSON objects cannot be numerically accessed.
Yes, but making it explicit is clearer.
This looks okay, and it aligns the text with the previous paragraph.

only if that object has a member with that name.  Nothing is selected from a value that is not a object.  <ins> The "index-selector" applied with an "element-index" to an array selects an array element using a zero-based index.  For example, selector "[0]" selects the first and selector "[4]" the fifth element of a sufficiently long array.  Nothing is selected, and it is not an error, if the index lies outside the range of the array.  Nothing is selected from a value that is not an array. </ins> A negative "element-index" counts from the array end.  For example, selector "[-1]" selects the last and selector "[-2]" selects the


of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one <del> of the selector entries is kept as many times in the node list. </del>  To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem-

of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one  <ins> of the selector entries is kept as many times in the nodelist. </ins> To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem-