Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rephrase security rules in terms of authentication #15

Closed
wants to merge 1 commit into from
Closed

Rephrase security rules in terms of authentication #15

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 11 additions & 27 deletions draft-ietf-add-resolver-info.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -109,17 +109,7 @@ Encrypted DNS resolver:
If the Special-Use Domain Name "resolver.arpa", defined in
{{!RFC9462}}, is used to discover an encrypted DNS resolver, the
client can retrieve the resolver information using the RESINFO RR
type and QNAME of "resolver.arpa". If a resolver supports DDR
but does not support RESINFO, the client can receive a positive RESINFO
response from a legitimate upstream DNS resolver or an attacker. While DNSSEC can be considered as a candidate mechanism
to protect against the attack, it is important to note that DNSSEC protection is not possible with
"resolver.arpa" due to the lack of uniqueness. To prevent such an attack,
resolvers supporting DDR MUST convey the "sig" attribute as defined in {{key-val}}. DNS clients
using DDR for encrypted resolver discovery querying for a RESINFO RR MUST validate the signature
in the "sig" attribute for data origin authentication using the public key
in the certificate, including ensuring that the certificate contains
the IP address that DDR uses for validation as per {{Section 4.2 of RFC9462}}.
If the signature validation fails, the DNS client MUST reject the RESINFO RR.
type and QNAME of "resolver.arpa".

# Format of the Resolver Information {#format}

Expand Down Expand Up @@ -185,17 +175,6 @@ Encrypted DNS resolver:
This is an optional attribute. For example, a DoT server may
not want to host an HTTPS server.

sig:
: It contains the signature of the RESINFO RR excluding the "sig"
attribute. The signature is generated by the encrypted DNS
resolver using all of the attributes in the RESINFO RR except the "sig" attribute.
The signature algorithm MUST be compatible with the public key in the DNS resolver's
end-entity certificate. As a reminder, the server's end-entity certificate's
public key will be compatible with the selected authentication algorithm from
the client's "signature_algorithms" TLS extension ({{Section 4.4.2.2 of !RFC8446}}).

This is an optional attribute.

New keys can be defined as per the procedure defined in {{key-reg}}.

{{ex-1}} shows an example of a published resolver information record:
Expand All @@ -207,14 +186,19 @@ resolver.example.net. 7200 IN RESINFO qnamemin exterr=15,16,17
{: #ex-1 title='An Example of Resolver Information Record' artwork-align="center"}


# Security Considerations
# Security Considerations {#security}

To be considered authenticated, a RESINFO response MUST meet one of the following conditions:

1. It appears in the Authority section of a response from the resolver it describes.
2. It is accompanied by a valid DNSSEC signature.
3. It appears in the Answer section of a response with DNSSEC OK set to 1 from a trusted resolver over a secure channel.

To prevent DNS response forgery attacks, DNS clients using DNR MUST employ one of the following measures:
The authentication provided under conditions 1 and 3 is limited by the DNS transport. Use of these conditions with insecure transports NOT RECOMMENDED, but may be appropriate in low-risk use cases. Note that of these conditions, only condition 1 can apply to queries for "resolver.arpa".

1. Establish an authenticated secure connection to the DNS resolver.
2. Implement local DNSSEC validation ({{Section 10 of ?RFC8499}}) to verify the authenticity of the resolver information.
If a RESINFO record is not authenticated, it could have been injected by a party who does not otherwise control the resolution process (i.e., an attacker).

In order to prevent DNS response forgery attacks, DNS clients using DDR MUST perform the validation explained in {{retreive}} for data origin authentication of RESINFO RR.
Even if a RESINFO response is authenticated, the correctness of the RESINFO contents cannot be verified. When connecting to an untrusted resolver, clients MUST account for the possibility that the RESINFO record contains false claims about the server.

# IANA Considerations

Expand Down