< draft-wijngaards-dnsop-confidentialdns-02.txt   draft-wijngaards-dnsop-confidentialdns-03.txt >
DNSOP Working Group W. Wijngaards DNSOP Working Group W. Wijngaards
Internet-Draft NLnet Labs Internet-Draft NLnet Labs
Intended status: Standards Track G. Wiley Intended status: Standards Track G. Wiley
Expires: March 8, 2015 VeriSign, Inc. Expires: September 7, 2015 VeriSign, Inc.
September 4, 2014 March 6, 2015
Confidential DNS Confidential DNS
draft-wijngaards-dnsop-confidentialdns-02 draft-wijngaards-dnsop-confidentialdns-03
Abstract Abstract
This document offers opportunistic encryption to provide privacy for This document offers opportunistic encryption to provide privacy for
DNS queries and responses. DNS queries and responses.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 8, 2015. This Internet-Draft will expire on September 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ENCRYPT RR Type . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Server and Client Algorithm . . . . . . . . . . . . . . . . . . 4
4. Authenticated Operation . . . . . . . . . . . . . . . . . . . . 6
5. Comparison with TLS and DTLS . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The privacy of the Question, Answer, Authority and Additional The privacy of the Question, Answer, Authority and Additional
sections in DNS queries and responses is protected by the sections in DNS queries and responses is protected by the
confidential DNS protocol by encrypting the contents of each section. confidential DNS protocol by encrypting the contents of each section.
The goal of this change to the DNS protocol is to make large scale The goal of this change to the DNS protocol is to make large scale
monitoring more expensive, see [draft-bortzmeyer-dnsop-dns-privacy] monitoring more expensive, see [draft-bortzmeyer-dnsop-dns-privacy]
and [draft-koch-perpass-dns-confidentiality]. Authenticity and and [draft-koch-perpass-dns-confidentiality]. Authenticity and
integrity may be provided by DNSSEC, this protocol does not change integrity may be provided by DNSSEC, this protocol does not change
DNSSEC and does not offer the means to authenticate responses. DNSSEC and does not offer the means to authenticate responses.
skipping to change at page 3, line 30 skipping to change at page 2, line 34
The confidential DNS protocol has minimal impact on the number of The confidential DNS protocol has minimal impact on the number of
packets involved in a typical DNS query/response exchange by packets involved in a typical DNS query/response exchange by
leveraging a cacheable ENCRYPT Resource Record and an optionally leveraging a cacheable ENCRYPT Resource Record and an optionally
cacheable shared secret. The protocol supports selectable cacheable shared secret. The protocol supports selectable
cryptographic suites and parameters (such as key sizes). cryptographic suites and parameters (such as key sizes).
The client fetches an ENCRYPT RR from the server that it wants to The client fetches an ENCRYPT RR from the server that it wants to
contact. The public key retrieved in the ENCRYPT RR is used to contact. The public key retrieved in the ENCRYPT RR is used to
encrypt a shared secret or public key that the client uses to encrypt encrypt a shared secret or public key that the client uses to encrypt
the sections in the DNS query and which the name server uses to the sections in the DNS query and which the name server uses to
encrypt the DNS response. Note that an ENCRYPT RR must be fetched encrypt the DNS response.
for each name server in order for the entire session to be
confidential.
As this is opportunistic encryption, the key is (re-)fetched when the As this is opportunistic encryption, the key is (re-)fetched when the
exchange fails. If the key fetch fails or the encrypted query fails, exchange fails or after the TTL expires. If the key fetch fails or
communication in the clear may be performed. the encrypted query fails, communication in the clear is performed.
The server advertises which crypto suites and key lengths may be used The server advertises which crypto suites and key lengths may be used
in the ENCRYPT RR, the client then chooses a crypto suite from this in the ENCRYPT RR, the client then chooses a crypto suite from this
list and includes that selection in subsequent DNS queries. list and includes that selection in subsequent DNS queries.
The key from the server can be cached by the client, using the TTL The key from the server can be cached by the client, using the TTL
specified in the ENCRYPT RR, the IP address of the server specified in the ENCRYPT RR, the IP address of the server
distinguishes keys in the cache. The server may also cache shared distinguishes keys in the cache. The server may also cache shared
secrets and keys from clients. secrets and keys from clients.
The optional authenticated mode of operation uses two mechanisms, one
for authoritative and one for recursive servers, that fetch the
public key for the server and sign it with DNSSEC. For authoritative
servers, the key is included in an extra DS record in the parent's
delegation. For recursive servers the key is at the reverse IP
address location.
2. ENCRYPT RR Type 2. ENCRYPT RR Type
The RR type for confidential DNS is ENCRYPT TBD (decimal). The The RR type for confidential DNS is ENCRYPT, type TBD (decimal). The
presentation format is: presentation format is:
. ENCRYPT [flags] [algo] [id] [data] . ENCRYPT [flags] [algo] [id] [data]
The flags, algo and id are unsigned numbers in decimal and the data The flags, algo and id are unsigned numbers in decimal and the data
is in base-64. The wireformat is: one octet flags, one octet algo, is in base-64. The wireformat is: one octet flags, one octet algo,
one octet id and the remainder of the rdata is for the data. The one octet id and the remainder of the rdata is for the data. The
type is class independent and it is a hop-by-hop transaction RR type. type is class independent. The domain name of the ENCRYPT record is
The domain name of the ENCRYPT record is '.' (the root label) for '.' (the root label) for hop-by-hop exchanges.
hop-by-hop exchanges.
In the flags the least two bits are used as usage value. The other In the flags the least two bits are the usage value. The other flag
flag bits MUST be ignored by receivers and sent as zeroes. bits MUST be sent as zeroes, and the receiver MUST ignore RRs that
have other flag bits set.
o PAD (value=0): the ENCRYPT contains padding material. Algo and id o PAD (usage=0): the ENCRYPT contains padding material. Algo and id
are set to 0. Its data length is random (say 1-63 octets), and are set to 0. Its data length varies (0-63 octets), and may
has some random values. It is a resource record that may be contain any value. It is used to pad packets to obscure the
appended to resource records that are encrypted so that identical packet length. Append such records to make the DNS message for
queries encrypt to different encrypted data of different lengths. queries and answers a whole multiple of 64 bytes.
o KEY (value=1): the ENCRYPT contains a public or symmetric key. o KEY (usage=1): the ENCRYPT contains a public or symmetric key.
The algo field gives the algorithm. The id identifies the key, The algo field gives the algorithm. The id identifies the key,
this id is copied to ENCRYPT type RRS to identify which key to use this id is copied to ENCRYPT type RRS to identify which key to use
to decrypt the data. The data contains the key bits. to decrypt the data. The data contains the key bits.
o RRS (value=2): encrypted data. The data contains encrypted o RRS (usage=2): encrypted data. The data contains encrypted
resource records. The data is encrypted with the selected resource records. The data is encrypted with the selected
algorithm and key id. The data contains resource records in DNS algorithm and key id. The data contains resource records in DNS
wireformat [RFC1034], with a domain name, type, class, ttl, wireformat [RFC1034], with a domain name, type, class, ttl,
rdatalength and rdata. rdatalength and rdata.
o SYM (value=3): the ENCRYPT contains an encrypted symmetric key. o SYM (usage=3): the ENCRYPT contains an encrypted symmetric key.
The contained, encrypted data is rdata of an ENCRYPT of type KEY The contained, encrypted data is rdata of an ENCRYPT of type KEY
and has the symmetric key. The data is encrypted with the and has the symmetric key. The data is encrypted with the
algorithm and id indicated. The encrypted data encompasses the algorithm and id indicated. The encrypted data encompasses the
flags, algo, id, data for the symmetric key. flags, algo, id, data for the symmetric key.
The ENCRYPT RR type can contain keys. It uses the same format as the The ENCRYPT RR type can contain keys. It uses the same format as the
DNSKEY record [RFC4034] for public keys. algo=0 is reserved for DNSKEY record [RFC4034] for public keys. algo=0 is reserved for
future expansion of the algorithm number above 255. algo=1 is RSA, future expansion of the algorithm number above 255. algo=1 is RSA,
the rdata determines the key size, such as 512 and 768 bits. algo=2 the rdata determines the key size. algo=2 is AES, aes-cbc, size of
is AES, aes-cbc, size of the rdata determines the size of the key, the rdata determines the size of the key.
such as 128 and 192 bits.
3. Server and Client Algorithm 3. Server and Client Algorithm
If a clients wants to fetch the keys for the server from the server, If a clients wants to fetch the keys for the server from the server,
it performs a query with query type ENCRYPT and query name '.' (root it performs a query with query type ENCRYPT and query name '.' (root
label). The reply contains the ENCRYPT (or multiple if a choice is label). The reply contains the ENCRYPT (or multiple if a choice is
offered) in the answer section. These ENCRYPTs have the KEY flag offered) in the answer section. These ENCRYPTs have the KEY usage.
set.
If a client wants to perform an encrypted query, it sends an If a client wants to perform an encrypted query, it sends an
unencrypted outer packet, with query type ENCRYPT and query name '.' unencrypted outer packet, with query type ENCRYPT and query name '.'
(root label). In the additional section it includes an ENCRYPT (root label). In the authority section it includes an ENCRYPT record
record of type RRS. This encrypts a number of records, the first is of type RRS. This encrypts a number of records, the first is a
a query-section style query record, and then zero or more ENCRYPTs of query-section style query record, and then zero or more ENCRYPTs of
type KEY that the server uses to encrypt the reply. If the client type KEY that the server uses to encrypt the reply. If the client
wants to use a symmetric key, there are no ENCRYPTs of type KEY wants to use a symmetric key, it omits the KEYs, and instead includes
inside the encrypted ENCRYPT data, instead an ENCRYPT of type SYM is an ENCRYPT of type SYM in the authority section. The ENCRYPT of type
positioned in the outer packet, before the ENCRYPT of type RRS and RRs then follows after the SYM and can be encrypted with the key from
the ENCRYPT of type RRS is encrypted with the symmetric key. that SYM.
If a server wants to encrypt a reply, it also uses the ENCRYPT type. If a server wants to encrypt a reply, it also uses the ENCRYPT type.
The reply looks like a normal DNS packet, i.e. it has a normal The reply looks like a normal DNS packet, i.e. it has a normal
unencrypted outer DNS packet. Because the query name and query type unencrypted outer DNS packet. Because the query name and query type
have been encrypted, the outer packet has a query name of '.' and have been encrypted, the outer packet has a query name of '.' and
query type of ENCRYPT and the reply has an ENCRYPT record in the query type of ENCRYPT and the reply has an ENCRYPT type RRS in the
answer section with flag RRS. The reply RRs have been encrypted into answer section. The reply RRs have been encrypted into the data of
the data of the ENCRYPT record. The RR counts for every section are the ENCRYPT record. The RRS data starts with 10 bytes of header; the
stored in the outer (unencrypted) header. Thus, the combination of flags and section counts.
the original header and the decrypted data from this record results
in the decrypted packet.
The client may lookup keys whenever it wants to. It may cache the The client may lookup keys whenever it wants to. It may cache the
keys for the server, using the TTL of those ENCRYPT records. It keys for the server, using the TTL of those ENCRYPT records. It
should also cache failures to lookup the ENCRYPT record for some time should also cache failures to lookup the ENCRYPT record for some
(eg. the negative TTL if the reply contained one). Errors and also time. If the client fails to look up the ENCRYPT records it MUST
timeouts should also be taken as an indication that the ENCRYPT fall back to unencrypted communication (this is the opportunistic
cannot be looked up, and the client MUST fall back to unencrypted encryption case). The result of an encrypted query may also be
communication (this is the opportunistic encryption case). The timeouts, errors or replies with mangled contents, in that case the
result of an encrypted query may also be timeouts, errors or replies client MUST fall back to unencrypted communication (this is the
with mangled contents, in that case the client MUST fall back to opportunistic encryption case).
unencrypted communication (this is the opportunistic encryption
case). Note that if some middlebox removes the ENCRYPT from the If some middlebox removes the ENCRYPT from the authority section of
additional section of an encrypted query, likely a reply with an encrypted query, the query looks like a . ENCRYPT lookup and
ENCRYPTs of type KEY is returned instead of the encrypted reply with likely a reply with ENCRYPTs of type KEY is returned instead of the
an ENCRYPT of type RRS, and again the client does the unencrypted encrypted reply with an ENCRYPT of type RRS, and again the client
fallback. If the server has changed its keys and does not recognize does the unencrypted fallback (this is the opportunistic encryption
the keys in an encrypted query, it should return FORMERR, and include case). If the server has changed its keys and does not recognize the
its current ENCRYPTs of type KEY in that FORMERR reply. A server may keys in an encrypted query, it should return an ENCRYPT record of
decide it does not (any longer) have the resources for encryption and type PAD with no data. A server may decide it does not (any longer)
reply with SERVFAIL to encrypted queries, forcing unencrypted have the resources for encryption and reply with SERVFAIL to
fallback. Keys for unknown algorithms should be ignored by the encrypted queries, forcing unencrypted fallback (this is the
client, if no usable keys remain, fallback to insecure. opportunistic encryption case). Keys for unknown algorithms should
be ignored by the client, if no usable keys remain, fallback to
insecure (this is for both opportunistic and authenticated).
The client may cache the ENCRYPT of type SYM for a server together The client may cache the ENCRYPT of type SYM for a server together
with the symmetric secret, this is better for performance, as public- with the symmetric secret, this is better for performance, as public-
key operations can be avoided for repeated queries. The server may key operations can be avoided for repeated queries. The server may
also cache the ENCRYPTs of type SYM with the decoded secret, also cache the ENCRYPTs of type SYM with the decoded secret,
associating a lookup for the rdata of the SYM record with the decoded associating a lookup for the rdata of the SYM record with the decoded
secret, avoiding public-key operations for repeated queries. secret, avoiding public-key operations for repeated queries. This is
why the SYM record is sent separately in the authority section in
queries (it is identical and can be used for cache lookups).
Key rollover is possible, use different key ids and support the old Key rollover is possible, support the old key for its TTL, while
key for its TTL, while advertising the new key, for the servers. For advertising the new key, for the servers. For clients, generate a
clients, generate a new public or symmetric key and use it. new public or symmetric key and use it.
4. Authenticated Operation 4. Authenticated Operation
The previous documented the opportunistic operation, where deployment The previous documented the opportunistic operation, where deployment
is easier, but security is weaker. This documents options for is easier, but security is weaker. This documents options for
authenticated operation. The client selects if encryption is authenticated operation. The client selects if encryption is
authenticated, opportunistic, or disabled in its local policy authenticated, opportunistic, or disabled in its local policy
(configuration). (configuration).
The authentication happens with a DNSSEC signed DS record that The authentication happens with a DNSSEC signed DS record that
carries the key for confidential DNS. This removes a full roundtrip carries the key for confidential DNS. This removes a full roundtrip
from the connection setup cost. The DS has hash type TBDhashtype, from the connection setup cost. The DS has hash type TBDhashtype,
that is specific for confidential DNS. The DS record carries a flag that is specific for confidential DNS. The DS record carries a flag
byte and the public key (in DNSKEY's wireformat) in its rdata data byte and the public key (in DNSKEY's wireformat) in its rdata. This
blob. This means that normally the confidential DNS keys are means that the confidential DNS keys are acquired with a referral to
acquired with a referral to a zone and can be authenticated with the zone and are secured with DNSSEC.
DNSSEC.
Because the key itself is carried, the probe sequence can be avoided Because the key itself is carried, the probe sequence can be omitted
and an encrypted query can be sent straight away. This makes the and an encrypted query can be sent to the delegated server straight
protocol about equally fast as normal DNS (from a packet latency away. The nameservers for that zone then MUST support using that key
point of view) for DNSSEC signed zones. The servers for that zone for encrypting packets. The servers have the same key with
have to share a public and private keypair between them that is used authenticated mode, where with the opportunistic mode, every server
to authenticate the encrypted queries and answers. That would be a could have its own key.
part of the nameserver configuration.
Because RFC4034 validators do not know this new hash type, they will Validators do not know or support the DS with ENCRYPT hash type,
ignore them and continue to DNSSEC validate the zone. Software that those validators ignore them and continue to DNSSEC validate the
understands the new DS hash type, know that the DS record really zone. Validators that support the new hash type should use them to
carries confidential DNS keys and not DNSKEY hashes. These should encrypt messages and use the remaining DS records to DNSSEC validate
continue to validate the zone with DNSSEC as normal with the the zone.
remaining DS records. If there are no other DS records with another
hash type, then the zone is not signed with DNSSEC, and the validator
should not require DNSSEC for the zone.
This changes the opportunistic encryption to authenticated This changes the opportunistic encryption to authenticated
encryption. The fallback to insecure is still possible and this may encryption. The fallback to insecure is still possible and this may
make deployment easier. The one byte at the start of the base64 make deployment easier. The one byte at the start of the base64
data, in its least significant bit, signals if fallback to insecure data, in its least significant bit, signals if fallback to insecure
is allowed (value 0x01). That gives the zone owner the option to is allowed (value 0x01). That gives the zone owner the option to
enable fallback to insecure or if it should be disabled. The enable fallback to insecure or if it should be disabled. The
remainder of the DS base64 data contains a public key in the same remainder of the DS base64 data contains a public key in the same
wireformat as a DNSKEY has public keys. The type of the key is in format as when sent in the rdata of ENCRYPT KEY. The type of the key
the key type field of this DS record. With fallback to insecure is in the key type field of this DS record. With fallback to
disabled and the keys authenticated the confidential DNS query and insecure disabled and the keys authenticated the confidential DNS
response should be fully secure (i.e. not 'Opportunistically' query and response should be fully secure (i.e. not
secure). [[Note: we could also put the flags in the keytag field]]. 'Opportunistically' secure).
With fallback to insecure disabled, queries fail instead of falling With fallback to insecure disabled, queries fail instead of falling
back to insecure. This means no answer is acquired, and DNS lookups back to insecure. This means no answer is acquired, and DNS lookups
for that zone fail because the security failed. for that zone fail because the security failed.
Servers with both downstream DNS clients and upstream DNS lookups The DS method works for authority servers. Recursors need another
MUST NOT give an answer to their downstream client when fallback to method. The client looks up reverse-of-recursors-IP.arpa ENCRYPT and
insecure is disabled and security fails, they MAY reply with gets the keys signed with DNSSEC from there (type ENCRYPT KEY
SERVFAIL. (this wording leaves wiggle room for ratelimiting by such lookup). If there is no dnssec secure answer with a key, the
servers). opportunistic key exchange is attempted. Do this for DNSSEC-insecure
answers, if there is no trust anchor, or when no such name and
The DS method works for authority servers. For recursors, ENCRYPT are present. If it is dnssec bogus, then authentication
authentication can be performed by getting the keys (or hashes) failed and it is not possible to communicate with the server (with
either from DHCP or configuration, the same path as the IP address the authenticated communication mode selected by the client).
for the recursor was configured. However, these methods are usually
very insecure. An improvement is for the client to cache the keys
for the resolver on stable storage. This is performed by the server
sending an RR together with the ENCRYPT keys in the key lookup, this
RR has a fallback-to-insecure flag, and a TTL value for caching the
key entry (suggested at 30 days). The cache TTL is set back at the
full value every time the confidential DNS keys are probed, according
to their normal TTL, which keeps the cache fresh. If the TTL time
has elapsed since the last time the keys were probed, the client
performs a new leap of faith, an insecure probe again. Keys can be
signed with RRSIGs made with (cached) keys, so key rollovers can be
performed. For relatively frequent queriers, this would make often
visited resolvers safe. The resolver is identified by its IP address
(perhaps coupled with the client idea of its 'network location', like
wifi ssid), and the keys are stored for that IP address.
The RR is ENCRYPT with flags 0x04 (STORE, please store keys on disk
for a a while, leap of faith style security), and flags 0x08
(fallback to insecure is allowed, or disabled). The id and algo are
sent zero, ignore on receipt. The data portion contains 4 bytes with
an unsigned 32 bit network byteorder number with a TTL in seconds for
the disk cache. The TTL expires that number of seconds after the
most recent ENCRYPT probe. More bytes in data portion, do not send,
ignore on receipt. So, ENCRYPT flag value 12 to store and allow
fallback to insecure could be sent along, or value 4 to disallow
fallback to insecure.
For authenticated operation, fallback to insecure should not be
performed. However, this will significantly harm deployment as
unclean lookup paths result in lookup failure. Keys with unsupported
crypto algorithms MUST still be ignored and if no keys are left,
fallback to insecure MUST still be performed, also for authenticated
operation.
The key for recursive resolvers can be configured into the stub
machines, or a domain name can be configured where the keys are
looked up and they are signed with DNSSEC.
5. Comparison with TLS and DTLS
An alternative method of accomplishing confidential DNS would be to
leverage one of the existing means for establishing a secure
transport layer. For example a secure TCP session could be
established to the name server over which DNS queries could be sent
with no changes to the DNS protocol. The most significant down side
to this approach is the burden that it places on high volume name
servers. Very large scale DNS operators expect to answer hundreds of
thousands of queries per second (possibly even more than a million
qps) for each host in their name server footprint. The use of
technologies such as IPSec or TLS may have such a severe impact on
the largest name server operators as to impede adoption of
confidential DNS.
DTLS (RFC 6347) offers a more interesting approach to securing the
connection to a name server that may be implemented in a way that is
less abusive to the large scale name servers. It looks as though the
overhead imposed by DTLS would probably be significantly higher than
the protocol described in this draft, however if the session
established via DTLS is used over a large number of queries then the
cost of the handshake could be amortized over the total number of
queries.
6. IANA Considerations 5. IANA Considerations
An RR type registration for type ENCRYPT with number TBD and it An RR type registration for type ENCRYPT with number TBD and it
references this document [[to be done when this becomes RFC]]. references this document [[to be done when this becomes RFC]].
A DS record hash type is registered TBDhashtype that references this A DS record hash type is registered TBDhashtype that references this
document. It is for the confidential DNS public key, acronym document. It is for the confidential DNS public key, acronym
CONFKEY. ENCRYPT.
7. Security Considerations 6. Security Considerations
Opportunistic encryption can be configured. Opportunistic encryption Opportunistic encryption can be configured. Opportunistic encryption
has many drawbacks, against active intrusion, but works against has many drawbacks against active intrusion, but it works against
passives. The pervasive passive surveillance problem statement and pervasive passive surveillance, and thus it improves privacy.
also its security considerations are applicable to this document.
Hence the suggested short key sizes and opportunistic encryption.
With authentication the key, if security works, is authenticated. With authentication (if selected by the client) the key is secured
With fallback to insecure disabled, security is full featured. The with DNSSEC.
keys are then signed by DNSSEC for authority servers, and a leap-of-
faith store after first contact security for resolvers that want
that.
This technique does not protect against timing, traffic analysis This technique encrypts DNS queries and answers, but other data
(what IP address is contacted), and the packet size, RR count, header sources, such as timing, IP addresses, and the packet size can be
flags and header RCODE can be observed. These could provide almost observed. These could provide almost all the information that was
all the information that was encrypted. Such as: query to IP address encrypted.
for example.com nameservers, size of the packet is similar to a
www.example.com lookup and is followed by http packets to
www.example.com's IP address.
8. Acknowledgments 7. Acknowledgments
Roy Arends Roy Arends
9. Normative References 8. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
 End of changes. 37 change blocks. 
193 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/