[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

DNSOP Working Group                                       P. Vixie, ISC
INTERNET-DRAFT                                         D. Dagon, GaTech
<draft-vixie-dnsext-dns0x20-00.txt>
Intended Status: Full Standard
Creation Date: March 17, 2008

                     Use of Bit 0x20 in DNS Labels
                    to Improve Transaction Identity


Status of this Memo
   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

                                 Abstract

   The small (16-bit) size of the DNS transaction ID has made it a
   frequent target for forgery, with the unhappy result of many cache
   pollution vulnerabilities demonstrated throughout Internet history.
   Even with perfectly and unpredictably random transaction ID's, random
   and birthday attacks are still theoretically feasible.  This document
   describes a method by which an initiator can improve transaction
   identity using the 0x20 bit in DNS labels.



Expires September 2008                                          [Page 1]

INTERNET-DRAFT                 March 2008                       DNS-0X20


1 - Introduction and Overview

1.1. This document explains the special relationship between the
question section of a DNS request and the question section of the
associated DNS response, and shows how this special relationship can be
used to convey information in a way that improves transaction identity,
making forgeries more expensive.

1.2. It will be argued that this special relationship, while not
mentioned in any DNS specification to date, happens to be almost
universally true among authority servers now operating on the Internet,
and is extremely valuable for its ability to convey information that
improves transaction identity, and ought to be made a part of the DNS
standard.

1.3. Implementation experience will be presented, showing the first
known use of this method, and the measured performance thereof.

1.4. 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 [RFC2119].

2 - Question Sections

2.1. In [RFC1035 7.3], the processing of responses is described,
including the step of verifying "that the question section corresponds
to the information currently desired".  This wording seems to leave open
several possibilities which are either unexplored or unexplorable,
including for example:

   That a response could be useful if its question is of current
   interest to the requestor even if it does not match any outstanding
   question; this is not practical since the question section of the
   response is used, along with the transaction ID, to demultiplex a
   particular response and match it to some outstanding request.

   That a response could "correspond to" a request in some way other
   than matching it exactly, implying the possibility of wildcarding, or
   parent domain inclusiveness, or other inexact matches such as case-
   folded matching as used by responders to look up DNS data in caches
   or in authority zones.

In practice, all question sections in responses are exact copies of
question sections from requests, even if the zone data and answer
section owner names differ in their uppercase/lowercase attributes from



Expires September 2008                                          [Page 2]

INTERNET-DRAFT                 March 2008                       DNS-0X20


the question section.  So while it is theoretically possible for a
request's question section to contain the name "www.ietf.org" and a
response's question section to contain the name "WWW.IETF.ORG", this has
not been observed, and might not even work reliably.

2.2. Because the question section is always, on today's Internet, copied
from the request exactly into the response, there is an opportunity to
use the 0x20 bit of any ASCII letter (in the ranges 0x41..0x5A and
0x61..0x7A, e.g., A..Z and a..z) in the question name, to convey
information from the requestor, to itself, via the responder.  For
example, the following question names will be treated as equal by a
responder, but can be treated as unequal by a requestor:

   www.ietf.org
   WWW.IETF.ORG
   WwW.iEtF.oRg
   wWw.IeTf.OrG


4 - Transaction Identity

4.1. The demultiplexing strategy recommended in [RFC1035 7.3] does not
accurately describe current practice.  For example, the "name server bug
typically encountered in UNIX system" is neither present nor accepted --
responders who answer from a source address other than the destination
of the request will not be heard.  Therefore the tuple used to match an
incoming RCODE=0 or RCODE=3 response to an outstanding OPCODE=0 question
is:

   <ip address, udp port, dns transaction id, qname, qclass, qtype>

4.2. Dan Bernstein showed how to randomize the <udp port>, thus
increasing transaction identity and therefore also the cost of forging a
response in a way that will fool a requestor and perhaps pollute a
cache.  However, this technique is not universally deployed, and it
relies on either a high number of concurrent udp ports, or a high churn
rate on udp ports, either of which can be impractical on high volume
embedded name servers.

4.3. Much effort has been expended in trying to make the DNS transaction
ID more random and less predictable.  Ultimately such efforts are
insufficient since with only 16 bits to fight over, a determined
attacker can use a purely random attack, or even a constant attack, and
theoretically, eventually, statistically speaking, break through the
requestor's defenses.



Expires September 2008                                          [Page 3]

INTERNET-DRAFT                 March 2008                       DNS-0X20


5 - Protocol Changes

5.1. By longitudinally encoding one bit of random information per ASCII
letter (in the ranges 0x41..0x5A and 0x61..0x7A, e.g., A..Z and a..z) in
the question name, the transaction ID can be effectively lengthened
beyond 16 bits.  Harkening back to our previous example, here are the
0x20 bits encoded into these question names:

   www.ietf.org  111 1111 111
   WWW.IETF.ORG  000 0000 000
   WwW.iEtF.oRg  010 1010 101
   wWw.IeTf.OrG  101 0101 010

As explained in Section 3 above, these bits MUST BE ignored by all
responders, and "happen to be" copied from the question section of the
request into the question section of the response by all known
responders, and thus function as a kind of "covert channel" from the
requestor, to itself, via the responder.

5.2. It is strongly urged that the DNS specification be amended to
require that the question section from the request MUST be copied,
exactly, bit for bit, into the question section of the response.  The
DNS specification is silent on the matter of altering 0x20 bits in the
question name when copying it from the request to the response, so, this
change is "within the spirit."

A change to the specification is necessary because while such bit for
bit copying "happens to be" nearly universal practice today, we must
warn all future responder implementors that the 0x20 bits, while not
significant for name matching, are now in use as a "covert channel" by
the requestor, to itself.

5.3. Requestor implementing this method should ideally signal an error
in their operations log when a mismatch in the 0x20 bits occurs, to help
measure global cache poisoning attempts, and to diagnose problems which
may be due to DNS middleboxes.

5.4. Requestors should take care to remember the original question name,
so that following successful verification of the 0x20-randomized
question name, the original can be copied into the response message
before the other sections are uncompressed.  This is because compression
pointers in the answer, authority, and additional section often point
back to the question section, with the ugly result of copying the
0x20-randomized bits into the cache, and into subsequent responses which
include data from the cache.



Expires September 2008                                          [Page 4]

INTERNET-DRAFT                 March 2008                       DNS-0X20


5.5. In the event of a question name mismatch where the QID, UDP port
number, question type, and question class all match, and the question
name mismatch is only in the 0x20 bits, then the response should be
discarded, and all addresses belonging to this server should be removed
from the SLIST (See [RFC1035 7.2]), and the requestor should continue
using other available servers (if any).  See also sections 6.2 .. 6.4
below.  If any of a zone's authoritative name servers can correctly echo
the randomized 0x20 bits, then the transaction should succeed when one
of those name servers is eventually reached.

6 - Implementation and Fallback

6.1. Several popular authoritative DNS implemenations including ISC BIND
(versions 4, 8, and 9), Nominum ANS, Akamai AKADNS, Neustar UltraDNS,
Verisign Atlas, NLNetLabs NSD, PowerDNS, and DJBDNS were tested.  All
copied the question name exactly, bit for bit, from the request into the
response.

6.2. Operational testing has revealed a small set of rare and/or private
label authoritative DNS implementations who modify the 0x20 bits in
question names while copying the question section from the request to
the response.  Usually this modification is to set the 0x20 bit, thus
converting a domain name to be all-lower-case (0x61..0x7A, e.g., a-z).

6.3. In order to utilize the method described above in section 5.1,
before all authoritative DNS servers have implemented the protocol
change described above in section 5.2, some kind of fallback strategy
must be employed.  Such strategy must have a similar security profile to
the method described above in section 5.1, or else an attacker could
force a victim to discard the benefits of using this method at all.

6.4. One fallback strategy, if all of a zone's authoritative name
servers fails to copy the 0x20 bits in the question name from the
request to the response, is to repeat the entire sequence, using newly
randomized query ID's (and other randomizable query elements, if in
use).  If possible, the repeated sequence should try the zone's
authority servers in a different (random) order each time.  If the
entire sequence is repeatable several times, where the random QID (and
other randomizable query elements, if any) are successfully echoed back
each time, then it is reasonable to ignore mismatches in the 0x20 bits.








Expires September 2008                                          [Page 5]

INTERNET-DRAFT                 March 2008                       DNS-0X20


7 - Security Considerations

7.1. No one knows when the next random number generator weakness will be
found, or how long it may take for Secure DNS to be deployed.  In fact,
no one really knows how many successful transaction ID guessing attacks
occur, or how much intentionally polluted cache data exists at any given
moment.

7.2. The method described here allows additional transaction identity to
be encoded in a request and verified in a response, thus increasing the
cost of DNS cache pollution attacks.

7.3. An unfortunate side effect of this approach is that longer domain
names, which contain more 0x20 bits, can encode more transaction
identity, and may thus yield better security against forgery and cache
pollution.  Thus, the domain "www.disney.com" (which has 12 extra bits
of transaction identity) is better protected against poisoning attacks
than the domain "cia.gov" (which yields only 6 extra bits).

7.4. Authority servers who strip the 0x20 bits from question names when
copying from the request to the response will see their query volumes
increase by a factor of "several" if the recommendations in section 6.4
above are followed.

7.5. Random number generators will expose more sequential state to
outside analysis under this proposal, especially if the recommendations
in section 6.4 above are followed.  This may give predictive attackers
an advantage.

8 - IANA Considerations

There is no work for IANA here.

9 - References

[RFC1035]  P. Mockapetris, "Domain Names - Implementation and
           Specification," RFC 1035, USC/Information Sciences Institute,
           November 1987.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, BCP14, March 1997.







Expires September 2008                                          [Page 6]

INTERNET-DRAFT                 March 2008                       DNS-0X20


10 - Authors' Addresses

Paul Vixie (text)

     Internet Software Consortium
     Redwood City, CA, USA
     EMail: vixie@isc.org


David Dagon (idea)

     Georgia Institute of Technology
     Atlanta, GA, USA
     EMail: dagon@cc.gatech.edu


































Expires September 2008                                          [Page 7]

INTERNET-DRAFT                 March 2008                       DNS-0X20


Full Copyright Statement

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors retain
all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights.  Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard.  Please address the information to the IETF at ietf-
ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).




Expires September 2008                                          [Page 8]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/