Internet DRAFT - draft-ohta-practically-secure-dns

draft-ohta-practically-secure-dns









INTERNET DRAFT                                                   M. Ohta
draft-ohta-practically-secure-dns-00.txt   Tokyo Institute of Technology
Intended status: Standard Track                         October 24, 2011
Expires: April 23, 2012

                         Practically Secure DNS

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute working
   documents as Internet-Drafts. The list of current Internet-Drafts is
   at http://datatracker.ietf.org/drafts/current.

   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."

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

   Plain DNS without PKI is secure, if a chain of query/response
   communications between a client and an authoritative server relayed
   by zero or more intermediate resolvers and the authoritative server
   and all the resolvers are secure.

   However, because of short (16bit) message ID, the communications
   composing the chain are not very secure without, or even with (port
   exhaustion attack is possible), source port randomization.




M. Ohta                 Expires on April 20, 2012               [Page 1]

INTERNET DRAFT           Practically Secure DNS             October 2011


   Still, plain DNS can be made practically secure, if the client makes
   two queries with independent message IDs to an address of a server (a
   resolver or a name server) and confirm that two replies are
   identical.

1. Security Considerations

   This memo proposes rather an implementation guideline than protocol
   modifications to DNS [DNS] to make DNS without PKI practically secure
   by letting a DNS client make two (or more, if necessary) queries,
   which are identical save cryptographically randomized message IDs, to
   a server (a resolver or a name server) over UDP and let the client
   check whether the replies are identical or not, ignoring inessential
   differences of RR ordering, character cases of labels and compression
   of labels.

   Queries should have identical source and destination addresses and
   randomized source port numbers.  The second query may immediately
   follow the first one without a randomized interval.

   While multiple queries increases the number of packets exchanged a
   little more than twice, the number of packets and associated
   computation load are expected to be considerably less than
   queries/replies over TCP (according to [TTCP], 10 packets are
   exchanged) and much less than those with [SDNS].

   If there is no reply after reasonable time out, it is a temporal
   failure.

   If there is only one reply after the reasonable time out, another
   query should be sent, failure to get the second reply after the
   reasonable time out is a temporal failure.

   If two replies are received but not identical, it should be because:

      1) versions of some zones related to the queries changes between
      the queries; or

      2) replies are constructed from different cache content; or

      3) the server is actively randomizing answers for load balancing
      and other purposes; or

      4) the client is under a message ID guessing attack.

   Even though two queries are made with a short interval, 1) and 2) can
   still occur, because zone version and cache content may change during
   the interval.



M. Ohta                 Expires on April 20, 2012               [Page 2]

INTERNET DRAFT           Practically Secure DNS             October 2011


   In any case, additional one or two queries, with different message
   IDs, should be generated.

   For cases 1), 2), 3) (only if randomization is based on client
   address) and 4), one or two more queries should be enough to have two
   identical replies, which should be practically secure. If no
   identical replies are available, it should be case 3) with truly
   random replies.

   During waiting replies, case 4) can be identified by replies with
   unmatched message IDs, which should initiate serious security alerts.

   Otherwise, it should be case 3) and, unless case 4) is identified to
   be simultaneously occurring, one of the replies should be practically
   secure, though it is less secure.  As DNS assumes "the system should
   be able to deal with subsets that change more rapidly (on the order
   of seconds or minutes)" [DNS], it is a natural consequence of
   randomizing servers to break the fundamental principle of DNS.  If
   case 3) and 4) is simultaneously occurring, it's a temporal failure.

   A resolver used by a practically secure DNS client should also behave
   as a client of practically secure DNS to make DNS practically secure
   end to end. However, then, the resolver must merge identical queries
   from its clients to prevent exponential growth of DNS traffic. If the
   resolver consists of internal multiple servers, identical queries
   should be forwarded to a single internal server based on source
   addresses of the queries, to prevent the exponential growth.

   A resolver unaware of practically secure DNS may generate multiple
   queries as a client, if corresponding multiple queries come from its
   clients.

2. IANA Considerations

   This document has no actions for IANA.

Normative References

   [DNS] STD0013.

Informative References

   [TTCP] R. Braden, "Extending TCP for Transactions -- Concepts", .
   RFC1379, November 1992.

   [SDNS] R. Arends, R. Austein, M. Larson, D. Massey and S. Rose, "DNS
   Security Introduction and Requirements".  RFC4033 , March 2005.




M. Ohta                 Expires on April 20, 2012               [Page 3]

INTERNET DRAFT           Practically Secure DNS             October 2011


Author's Address

   Masataka Ohta
   Graduate School of Information Science and Engineering
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku
   Tokyo 152-8552, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3299
   EMail: mohta@necom830.hpcl.titech.ac.jp








































M. Ohta                 Expires on April 20, 2012               [Page 4]