Signaling Cryptographic Algorithm Understanding in DNSSECShinkuro Inc.5110 Edgemoor LaneBethesda20814MDUSAsteve@shinkuro.com NIST 100 Bureau Dr.Gaithersburg20899MDUSA+1-301-975-8439 scott.rose@nist.gov
Internet Area
DNS Extensions Working Group DNSDNSSEC
The DNS Security Extensions (DNSSEC) was developed to provide origin
authentication and integrity protection for DNS data by using digital
signatures. These digital signatures can be generated
using different algorithms. Each digital signature added to a response
increases the size of the response, which could result in the response
message being truncated. This draft sets out to specify a way for
validating end-system resolvers
to signal to a server which cryptographic algorithms they prefer in a
DNSSEC response by defining an EDNS option to list a client's preferred
algorithms.
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.
The DNS Security Extensions (DNSSEC) was developed to provide origin
authentication and integrity protection for DNS data by using digital
signatures , and
. Each digital signature RR (RRSIG) contains an
algorithm code
number. These algorithm codes help validators identify which
cryptographic algorithm was used to generate the digital signature.
RRSIG RRs can be fairly large, and increase the size of a response. If
multiple algorithms are used, then multiple RRSIGs are returned for each
RRset in a response. If the response is too large, it may be truncated,
and the client forced to resend the query using TCP. It would be in
the client and server's interests if there was a way to limit the number
of RRSIGs in a response to only those algorithms the client was interested
in (if present).
This draft sets out to specify a way for validating end-system resolvers
to signal to a server which
cryptographic algorithms they prefer in a DNSSEC response. This is done
using the EDNS attribute values in the OPT meta-RR .
This option could also be used by servers to advertise which cryptographic
algorithms are used in signing a particular zone.
An additional reason for having the end-system resolver signal
which algorithms it
understands is to speed the transition to a new algorithm. A server will
be able to determine when to start serving a new algorithm when it sees a
sufficient number of its clients are able to accept the new algorithm
and it will be able to determine when to stop serving the old algorithm when
it sees that all or almost all of its clients are able to accept the new
algorithm. Information about clients can also be used to communicate to
the operators of those clients and/or the providers of their software that
it's time to upgrade.
The ENDS0 specification outlined in defines a
way to include new options using a standardized mechanism. These options are
contained in the RDATA of the OPT meta-RR. This document seeks to define
a new EDNS0 option for a client to signal which algorithms the client
prefers, and the server to advertise which algorithms are used to sign a
particular zone.
OPTION-CODE is the code for the Algorithm Understood (AU) option. Its value
is fixed at TBD.
OPTION-LENGTH is the length of the data of the attribute in octets.
DNSSEC algorithm codes are 1 octet long so this value is set at 1.
ALG-CODE is the assigned DNSSEC algorithm codes that the client indicates as
understood. This value SHOULD be the largest algorithm code value understood by the
validator (excluding Reserved codes, and values greater than 252). It is assumed
that the validator understands all previously defined (and
lower) algorithm codes. For example, if
a validating client understands RSA/SHA-1 and RSA/SHA-256 the value of ALG-CODE
would be: 8 (RSA/SHA-256), indicating that the validator understand both
RSA/SHA-256, RSA/SHA-1 and DSA but not ECC because it is currently reserved and not
defined.
A validating end-system resolver sets the AU option in the OPT meta-RR when sending a
query. The validating end-system resolver SHOULD set the value to be the largest
algorithm code that the validator understands (excluding Reserved codes and values
greater than 252).
A validating end-system resolver SHOULD only list algorithm codes that the
client has
implemented. Conversely, a validating end-system resolver SHOULD NOT include
the algorithm code for cryptographic algorithms for which they have
not implemented.
The end-system resolver MUST also set the DNSSEC-OK bit to
indicate
that it wishes to receive DNSSEC RRs in the response.
Stub resolvers rely on an upstream recursive server (or cache) to provide
a response, any algorithm preference on the stub resolver's side can be
overruled by the upstream recursive server. The AU EDNS option is NOT
RECOMMENDED for non-validating stub clients.
The only exception is for validating stub resolvers, which set the CD
bit in queries. In this scenario, the validating stub indicates that it
wishes to perform its own validation and may wish to indicate which
cryptographic algorithm it prefers.
When an authoritative server sees the AU option in the OPT meta-RR in a
request the normal algorithm for servicing requests is followed. The only
difference is what DNSSEC RRs are included in the final response.
If the AU option is present but the DNSSEC-OK bit is not set, then the
authoritative server does not include any additional DNSSEC RRs in the
response. If the DNSSEC-OK bit is set, the authoritative server looks at
the ALG-CODE value in the OPT meta-RR, selects the RRSIGs with the algorithm
code equal to or lower (whichever is closest) to be included in the response
(as per the rules in ).
If the zone containing the QNAME is not signed, the authoritative server
sends a traditional non-DNSSEC response. If the zone containing the QNAME
is signed with a cryptographic algorithm(s) that are all greater than the
ALG-CODE value in the client query the authoritative server SHOULD include
any or all RRSIGs in the response regardless of algorithm used to
generate them.
Caches MUST NOT set the AU option on any outgoing query from the cache when
performing recursion on behalf of a stub client. A cache MUST follow the
guidelines in the DNSSEC specification (, ,
and any updating documents).
If a cache receives a query with the AU option set and the response can be
answered
by data out of the cache, the cache SHOULD follow the AU option request
and
only include the RRSIGs generated using the algorithm equal to or less than
the value in ALG-CODE.
Forwarders that do not do validation or caching MAY copy the AU option
seen
in received queries as they represent the wishes of the validating
downstream resolver that issued the original query.
Intermediate resolvers SHOULD copy the AU option seen in queries from end-
system resolvers. If the intermediate resolver is validating, it SHOULD
also check for the presence of the CD bit in the query. If present, the
intermediate resolvers SHOULD copy the AU option as seen in the query. If
not or if the DNSSEC-OK bit is not set, then the validating intermediate
resolver MAY chose to ignore the AU option in the query and MAY include
its own preference as the AU option.
The algorithm codes used to identify DNSSEC algorithms has already been
established by IANA. This document does not seek to alter that registry
in any way.
This draft seeks to update the "DNS EDNS0 Options" registry by adding the
AU option and referencing this document. The code for the option should
be TBD.
This document specifies a way for a client to signal its digital signature
algorithm preference to a cache or server. It is not meant to be a
discussion
on algorithm superiority. The signal is an optional code contained in
the OPT meta-RR used with EDNS0. The goal of this option is to reduce
response size by having the client signal with digital signature
algorithms it prefers and that it may not care about other algorithms used
to sign zone data.
It is possible that an attacker can attempt to conduct a downgrade attack
by intercepting the query and altering the AU option code. An attacker
could alter the algorithm list to force the client to rely on a
weaker digital signature algorithm even though the zone is signed using a
stronger algorithm the client prefers. In these cases a client might
be able to detect an attack if the target zone has a DS RR in its delegating
parent with the desired algorithm. The DS cannot be deleted without making the
parent's RRSIG over that RRset invalid.