DNS Server Selection:
DNS Server Information with Assertion TokenMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comCitrix Systems, Inc.USAdwing-ietf@fuggles.comSandelman Software WorksUSAmcr+ietf@sandelman.caOrangeRennes35000Francemohamed.boucadair@orange.comADD WGThe document defines a mechanism that is meant to communicate DNS
resolver information to DNS clients for use as a criteria for server
selection decisions. Such an information that is cryptographically
signed to attest its authenticity is used for the selection of DNS
resolvers. Typically, evaluating the resolver information and the
signatory, DNS clients with minimal or no human intervention can select
the DNS servers for resolving domain names.This assertion is useful for encrypted DNS (e.g., DNS-over-TLS,
DNS-over-HTTPS, or DNS-over-QUIC) servers that are either public
resolvers or discovered in a local network. discusses DNS privacy considerations
in both "on the wire" (Section 2.4 of )
and "in the server" (Section 2.5 of )
contexts. Examples of protocols that provide encrypted channels between
DNS clients and servers are DNS-over-HTTPS (DoH) , DNS-over-TLS (DoT) , and DNS-over-QUIC (DoQ) .DNS clients can discover and authenticate encrypted DNS servers
provided by a local network, for example using the techniques proposed
in [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr]. If the mechanism used to
discover the encrypted DNS server is insecure, the DNS client needs
evidence about the encrypted server to assess its trustworthiness and a
way to appraise such evidence. The mechanism specified in this document
can be used by the DNS client to cryptographically identify if it is
connecting to an encrypted DNS server hosted by a specific organization
(e.g., ISP or Enterprise). This strengthens the protection as clients
can detect and reject connections to encrypted DNS servers hosted by
attackers.This document also defines a mechanism for DNS clients to gather a
set of resolver information related to discovered (or preconfigured) DNS
servers and use that information to feed a DNS server selection
procedure.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and
only when, they appear in all capitals, as shown here.This document makes use of the terms defined in and .'Encrypted DNS' refers to a DNS protocol that provides an encrypted
channel between a DNS client and server (e.g., DoT, DoH, or DoQ).The terms 'Evidence', 'Verifier', 'Background Check', 'Relying
Party', 'Appraisal Policy', and 'Attestation Results' are defined in
.The mechanism used in this specification resembles the
Background-Check Model discussed in Sections 5.2 and 5.3 of Remote
attestation procedure (RATS) Architecture . RATS enables a relying
party to establish a level of confidence in the trustworthiness of a
remote peer through the creation of Evidence to assess the peer's
trustworthiness, and an Appraisal Policy for such Evidence.In this document, the Relying Party is the DNS client and the
Attester is the encrypted DNS server. The Encrypted DNS servers MAY use
"Domain Validation" (DV) certificates for certificate-based server
authentication in TLS connections.The DNS server's resolver information needs to be validated and
signed. This signature is called an Attestation Result. This
validation can be performed by the DNS operator itself (signed by the
DNS operator's certificate) acting as a verifier or performed by an
external Verifier (signed by that external Verifier). The signing
certificate can to be an Extended Validation (EV) certificate issued by
a public CA in specific scenarios listed below. An EV certificate is
issued by the public CA after a thorough Background Check to verify the
requesting organization's legal identity. If the signing certificate is
a EV certificate, it leaves the client with a better audit trail of the
organization hosting the DNS server in comparison with the DV
certificate.The use of EV certificate is needed in the following scenarios:It helps the client to avoid sending DNS queries to an Encrypted
DNS server hosted by an attacker discovered insecurely (e.g., using
DHCP/RA or DNS). For example, an attacker can get a domain name,
domain-validated public certificate from a CA and host a Encrypted
DNS server. Furthermore, an attacker can use a public IP address,
get an 'IP address'-validated public certificate from a CA and host
a Encrypted DNS server.It can be used by the client to identify the Encrypted DNS server
is hosted by a legal organization.The use of EV certificate is not required in the following
scenarios:If the Encrypted DNS server can only be discovered securely
(e.g., using IKEv2 ),
the signing certificate need not be an EV certificate.Secure Zero Touch Provisioning
defines a bootstrapping strategy for enabling a networking device to
securely obtain the required configuration information with no user
input. If the encrypted DNS server is insecurely discovered and not
preconfigured in the networking device, the DNS client on the
networking device can validate the Resolver Assertion Token
signature using the owner certificate as per Section 3.2 of .JSON Web Token (JWT) and JSON Web
Signature (JWS) and related
specifications define a standard token format that can be used as a way
of encapsulating claimed or asserted information with an associated
digital signature using X.509 based certificates. JWT provides a set of
claims in JSON format that can accommodate asserted resolver information
of the Encrypted DNS server. Additionally, JWS provides a path for
updating methods and cryptographic algorithms used for the associated
digital signatures.JWS defines the use of JSON data structures in a specified canonical
format for signing data corresponding to JOSE header, JWS Payload, and
JWS Signature. The next sections define the header and claims that MUST
be minimally used with JWT and JWS for resolver assertion token.The Resolver Assertion Token (RAT) specifically uses this token
format and defines claims that convey the resolver information of
Encrypted DNS server.The client can retrieve the RAT object using the RESINFO RRtype
defined in and QNAME of the
domain name that is used to authenticate the DNS server (referred to as
ADN in ). If the special use domain name
"resolver.arpa" defined in [I-D.ietf-add-ddr] is used to discover the
Encrypted DNS server, the client can retrieve the RAT object using the
RESINFO RRtype and QNAME of the special use domain name.The signature of RAT object MUST be validated by the DNS client. If
signature is invalid, the RAT object is rejected. If signature is valid
and signer is trusted, the DNS client can use that encrypted DNS
server.The JWS token header is a JOSE header (Section 4 of ) that defines the type and encryption algorithm
used in the token.The RAT header MUST include, at a minimum, the header parameters
defined in Sections , , and .The 'typ' (Type) Header Parameter is defined in Section 4.1.9 of
to declare the media type of the
complete JWS.For RAT Token the 'typ' header MUST be the string 'rat'. This
represents that the encoded token is a JWT of type rat.The 'alg' (Algorithm) Header Parameter is defined in Section 4.1.1
of . It specifies the JWS signature
cryptographic algorithm. It also refers to a list of defined 'alg'
values as part of a registry established by JSON Web Algorithms (JWA)
Section 3.1.For the creation and verification of RAT tokens and their digital
signatures, implementations MUST support ES256 as defined in Section
3.4 of . Implementations MAY support
other algorithms registered in the JSON Web Signature and Encryption
Algorithms registry created by . The
content of that registry may be updated in the future depending on
cryptographic strength requirements guided by current security best
practice. The mandatory-to-support algorithm for RAT tokens may
likewise be updated in the future.Implementations of RAT digital signatures using ES256 as defined
above SHOULD use deterministic ECDSA when supported for the reasons
stated in .As defined in Section 4.1.5 of , the
'x5u' header parameter defines a URI
referring to the resource for the X.509 public key certificate or
certificate chain corresponding to the
key used to digitally sign the JWS. Generally, as defined in Section
4.1.5 of this corresponds to an HTTPS
or DNSSEC resource using integrity protection.An example of the RAT header is shown in .
It includes the specified RAT type, ES256 algorithm, and an URI
referencing the network location of the certificate needed to validate
the RAT signature.The token claims consist of the resolver information of the DNS
server that needs to be verified at the DNS client. These claims follow
the definition of a JWT claim (Section 4 of ) and are encoded as defined by the JWS Payload
(Section 3 of ).RAT defines the use of a standard JWT-defined claim as well as custom
claims corresponding to the DoT or DoH servers.Claim names MUST use the US-ASCII character set. Claim values MAY
contain characters that are outside the ASCII range, however they MUST
follow the default JSON serialization defined in Section 7 of .The JSON claim MUST include the 'iat' (Section 4.1.6 of ) defined claim "Issued At". The 'iat'
should be set to the date and time of issuance of the JWT. The time
value should be of the format (NumericDate) defined in Section 2 of
.The JSON claim MUST include the 'exp' (Section 4.1.4 of ) defined "claim Expiration Time". The 'exp'
should be set to specify the expiration time on or after which the
JWT is not accepted for processing. The RAT object should expire
after a reasonable duration. A short expiration time for the RAT
object periodically reaffirms the resolver information of the DNS
server to the DNS client and ensures the DNS client does not use
outdated resolver information. If the DNS client knows the RAT
object has expired, it should make another request to get the new
RAT object from the DNS server.The DNS server identity is represented by a claim that is
required for RAT: the 'server' claim. The 'server' MUST contain
claim values that are identity claim JSON objects where the child
claim name represents an identity type and the claim value is the
identity string, both defined in subsequent subsections.These identities can be represented as either authentication
domain name (ADN) (defined in ) or
Uniform Resource Indicators (URI).The DNS client constructs a reference identifier for the DNS
server based on the ADN or the domain portion in the URI of the DNS
server identity. The domain name in the DNS-ID identifier type
within subjectAltName entry in the DNS server certificate conveyed
in the TLS handshake is matched with the reference identifier. If
the match is not successful, the client MUST not accept the RAT for
further processing.If the DNS server identity is an ADN, the claim name
representing the identity MUST be 'adn'. The claim value for the
'adn' claim is the ADN.If the DNS server identity is of the form URI Template, as
defined in , the claim name
representing the identity MUST be 'uri' and the claim value is the
URI Template form of the DNS server identity.As a reminder, if DoH is supported by the DNS server, the DNS
client uses the URI Template (Section 3 of ).The 'resinfo' claim MUST be formatted as a JSON object. The JSON
object MUST use the I-JSON message format defined in . Note that
was based on , but was replaced by . Requiring the use of I-JSON instead of
more general JSON format greatly increases the likelihood of
interoperability.The 'resinfo' claim contains the resolver information of the DNS
server, it includes the following attributes:If the DNS server supports
QNAME minimisation to improve DNS
privacy, the parameter value is set to true. This is a mandatory
attribute.If the DNS server supports
extended DNS error (EDE) to
return additional information about the cause of DNS errors, the
parameter lists the possible extended DNS error codes that can
be returned by the DNS server. This is an optional attribute.
Note that the extended error code "Blocked" defined in
Section 4.16 of identifies
access to domains is blocked due to an policy by the
operator of the DNS server, extended error code "Censored"
defined in Section 4.17 of
identifies access to domains is blocked based on a
requirement from an external entity and the extended error
code "Filtered" defined in Section 4.18 of identifies access to domains is
blocked based on the request from the client to blacklist
domains.If the DNS server requires client
authentication, the parameter value is set to true. For example,
when not on the enterprise network (e.g., at home or coffee
shop) yet needing to access the enterprise Encrypted DNS server,
roaming users can use client authentication to access the
Enterprise provided Encrypted DNS server. This is an optional
attribute.A URL that points to the generic
unstructured resolver information (e.g., DoH APIs supported,
possible HTTP status codes returned by the DoH server, how to
report a problem, etc.) for troubleshooting purpose. This is an
optional attribute.A URL that points to a human-friendly
description of the resolver identity to display to the
end-user. shows an example of resolver
information.The signature of the RAT is created as specified in Section 5.1 of
(Steps 1 through 6). RAT MUST use the JWS
Protected Header.For the JWS Payload and the JWS Protected Header, the lexicographic
ordering and white space rules described in and , and
JSON serialization rules in
MUST be followed.The RAT is cryptographically signed by the domain hosting the DNS
server and optionally by a third party who performed privacy and
security audit of the DNS server.The resolver information is attested using "Extended Validation" (EV)
certificate to avoid bad actors taking advantage of this mechanism to
advertise encrypted DNS servers for illegitimate and fraudulent purposes
meant to trick DNS clients into believing that they are using a
legitimate encrypted DNS server hosted to provide privacy for DNS
transactions.Alternatively, a DNS client has to be configured to trust the leaf of
the signer of the RAT object. That is, trust of the signer MUST NOT be
determined by validating the signer via the OS or the browser trust
chain because that would allow any arbitrary entity to operate a DNS
server and assert any sort of resolver information.
provides an example of how to follow the steps to create the JWS
Signature.JWS JSON serialization (Step 7 in Section 5.1 of ) is supported for RAT to enable multiple
signatures to be applied to the RAT object. For example, the RAT object
can be cryptographically signed by the domain hosting the DNS server and
by a third party who performed privacy and security audit of the DNS
server.
includes an example of the full JWS JSON serialization representation
with multiple signatures.Section 5.1 of (Step 8) describes the
method to create the final JWS Compact Serialization form of the RAT
Token.RAT includes the minimum set of claims needed to securely assert the
resolver information of the DNS server. JWT supports a mechanism to add
additional asserted or signed information by simply adding new claims.
RAT can be extended beyond the defined base set of claims to represent
other DNS server information requiring assertion or validation.
Specifying new claims follows the baseline JWT procedures (Section 10.1 of ). Understanding new claims on
the DNS client is optional. The creator of a RAT object cannot assume
that the DNS client will understand the new claims.JSON objects can include spaces and line breaks, and key value pairs
can occur in any order. It is therefore a non-deterministic string
format. In order to make the digital signature verification work
deterministically, the JSON representation of the JWS Protected Header
object and JWS Payload object MUST be computed as follows.The JSON object MUST follow the following rules. These rules are
based on the thumbprint of a JSON Web Key (JWK) as defined in Section 3
of (Step 1).The JSON object MUST contain no whitespace or line breaks before
or after any syntactic elements.JSON objects MUST have the keys ordered lexicographically by the
Unicode code points of the member
names.JSON value literals MUST be lowercase.JSON numbers are to be encoded as integers unless the field is
defined to be encoded otherwise.Encoding rules MUST be applied recursively to member values and
array values.This section demonstrates the deterministic JSON serialization for
the example RAT Payload shown in .The initial JSON object is shown in .The parent members of the JSON object are as follows, in
lexicographic order: "exp", "iat", "resinfo", "server".The final constructed deterministic JSON serialization
representation, with whitespace and line breaks removed, (with line
breaks used for display purposes only) is:This document defines the following entries for the IANA DNS Resolver
Information Registry that is defined in .The "server" name containing the DNS server identity discussed in
.The sub-attribute "adn" discussed in
contained in the "server" attribute is used to specify the DNS
server identity in the form of ADN.The sub-attribute "uri" discussed in
contained in the "server" attribute is used to specify the DNS
server identity in the form of URI template.The "resinfourl", "extendeddnserror" and "qnameminimization"
names containing the resolver information of the DNS server
discussed in .The "attested-resinfo" name contains a base64 encoding of a RAT
. If the "attested-resinfo" name is
conveyed to the client, the server need not convey the above
attributes (1 to 5) separately as that resolver information will be
extracted by the client from the RAT payload.The use of RAT object based on the validation of the digital
signature and the associated certificate requires consideration of the
authentication and authority or reputation of the signer to attest the
resolver information of the DNS server being asserted. Bad actors can
host encrypted DNS servers to invade the privacy of the user. Bad actor
can get a domain name, host encrypted DNS servers, and get the DNS
server certificate signed by a CA. The resolver information will have to
be attested using EV certificates or a RAT object signer trusted by the
DNS client to prevent the attack.The CA that issued the EV certificate does not attest the resolver
information. The organization hosting the DNS server attests the
resolver information using the EV certificate and the client uses the EV
certificate to identify the organization (e.g., ISP or Enterprise)
hosting the DNS server.If the RAT object is asserted by a third party, it can do a "time of
check" but the DNS server is susceptible of "time of use" attack. For
example, changes to the DNS server can cause a disagreement between the
auditor and the DNS server operation, hence the RAT object needs to be
also asserted by the domain hosting the DNS server. In addition, the RAT
object needs to have a short expiration time (e.g., 7 days) to ensure
the DNS server's domain re-asserts the resolver information and limits
the damage from change in behaviour and mis-issuance.This section registers the 'application/rat' media type in the 'Media Types' registry in the manner
described in , which can be used to
indicate that the content is a RAT defined JWT.Type name: applicationSubtype name: ratRequired parameters: n/aOptional parameters: n/aEncoding considerations: 8bit; application/rat values are
encoded as a series of base64url-encoded values (some of which
may be the empty string) separated by period (‘.’)
characters..Security considerations: See the Security Considerations
Section of .Interoperability considerations: n/aPublished specification: [THIS_DOCUMENT]Applications that use this media type: DNSFragment identifier considerations: n/aAdditional information: Magic
number(s): n/a File extension(s): n/a Macintosh file type
code(s): n/aPerson & email address to contact for further
information: Tirumaleswar Reddy, kondtir@gmail.comIntended usage: COMMONRestrictions on usage: noneAuthor: Tirumaleswar Reddy, kondtir@gmail.comChange Controller: IESGProvisional registration? NoIANA is requested to assign the following claims in the registry
maintained in: https://www.iana.org/assignments/jwt/jwt.xhtml.Claim Name: 'server'Claim Description: DNS server identityChange Controller: IESGSpecification Document(s): of [THIS_DOCUMENT]Claim Name: 'resinfo'Claim Description: Resolver information of DNS server.Change Controller: IESGSpecification Document(s):
of [THIS_DOCUMENT]IANA will add the names "attested-resinfo", "server", "resinfourl",
"identityurl", "extendeddnserror" and "qnameminimization" to the DNS
Resolver Information registry defined in Section 4.2 of .IANA will add "adn" and "uri" sub-attributes contained in the
"server" attribute to the DNS Resolver Information registry.This specification leverages some of the work that has been done in
. Thanks to Tommy Jensen, Ted Lemon, Paul
Wouters, Neil Cook, Vittorio Bertola, Vinny Parla, Chris Box, Ben
Schwartz and Shashank Jain for the discussion and comments.The Unicode StandardThe Unicode ConsortiumFor RAT, there will always be a JWS with the following members:'protected', with the value BASE64URL(UTF8(JWS Protected
Header))'payload', with the value BASE64URL (JWS Payload)'signature', with the value BASE64URL(JWS Signature)This example will follow the steps in JWS Section 5.1, steps 1-6 and 8 and incorporates
the additional serialization steps required for RAT.Step 1 for JWS references the JWS Payload, an example RAT Payload is
as follows:This would be serialized to the form (with line break used for
display purposes only):Step 2 Computes the BASE64URL(JWS Payload) producing this value (with
line break used for display purposes only):For Step 3, an example RAT Protected Header comprising the JOSE
Header is as follows:This would be serialized to the form (with line break used for
display purposes only):Step 4 Performs the BASE64URL(UTF8(JWS Protected Header)) operation
and encoding produces this value (with line break used for display
purposes only):Step 5 and Step 6 performs the computation of the digital signature
of the RAT Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) ||
‘.’ || BASE64URL(JWS Payload)) using ES256 as the algorithm
and the BASE64URL(JWS Signature).Step 8 describes how to create the final RAT token, concatenating the
values in the order Header.Payload.Signature with period
(‘.’) characters. For the above example values this would
produce the following (with line breaks between period used for
readability purposes only):The JWS payload used in this example as follows.This would be serialized to the form (with line break used for
display purposes only):The JWS protected Header value used for the first signature is same
as that used in the example in .
The X.509 private key used for generating the first signature is same as
that used in the example in .The JWS Protected Header value used for the second signature is:The complete JWS JSON Serialization for these values is as follows
(with line breaks within values for display purposes only):