[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Intended status: Standards Track                          August 4, 2010
Expires: February 5, 2011


 Using Secure DNS to Retrieve Keys Used for Authenticating TLS Servers
                   draft-hoffman-tls-keys-from-dns-00

Abstract

   TLS requires the use of PKIX certificates for authenticating the
   server.  Some people want to obtain the public key used in this
   authentication using other methods.  This document describes how to
   securely retrieve a TLS server's public key from the 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."

   This Internet-Draft will expire on February 5, 2011.

Copyright Notice

   Copyright (c) 2010 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.




Hoffman                 Expires February 5, 2011                [Page 1]


Internet-Draft            TLS Keys from the DNS              August 2010


1.  Introduction

   The first response from the server in TLS [RFC5246] contains a PKIX
   certificate.  In order for the TLS client to authenticate that it is
   talking to the expected TLS server, the client must validate that the
   key in this certificate is associated with the domain name used by
   the client to get to the server.  To do this, the client must extract
   the domain name from one of many places in the PKIX certificate, must
   trust the trust anchor upon which the server's PKIX certificate is
   rooted, and must7 perform correct PKIX validation on the certificate.

   Some people want a different way to authenticate the server without
   using PKIX.  In order to do this, the TLS client must have a copy of
   the TLS server's key that was received in a trusted fashion, and a
   trusted belief that the key is associated with the domain name used
   to reach the TLS server.  This key and association can be gotten out
   of band, but a more scalable way to get them is by using the DNS.

   DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033],
   [RFC4034], and [RFC4035]), uses cryptographic keys and digital
   signatures to provide authentication of DNS data.  Information
   retrieved from the DNS and that is validated using DNSSEC is thereby
   proved to be the authoritative data.

   This document defines a secure method to get a key usable in TLS for
   a particular domain name using DNS protected by DNSSEC.  Because the
   key was retrieved based on a DNS query, the domain name in the query
   is by definition associated with the key.  This document also defines
   different ways that the key can be used in TLS.

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

   NOTE TO READERS: THIS DOCUMENT HAS KNOWN HOLES AND ONE GLARING
   PROBLEM, NAMELY THAT THERE ARE TWO METHODS DEFINED WHILE ONLY ONE
   WILL BE CHOSEN LATER.


2.  Getting TLS Keys from the DNS

   This section describes two equivalent methods for encoding TLS keys:
   a new RR called "TLSKEY" and a TXT record that can be emitted when
   the query has "_TLSKEY" as the leftmost label.  Only one of these
   methods should be selected for the final protocol.  When that
   decision is made, the method not used will be removed from this
   document.




Hoffman                 Expires February 5, 2011                [Page 2]


Internet-Draft            TLS Keys from the DNS              August 2010


2.1.  The TLSKEY Resource Record

   The new RR TLSKEY is defined here.  A query on a domain name for the
   TLSKEY type can return one or more records of the type TLSKEY.

   The format of the TLSKEY response is binary.  In the record, all
   integers consist of two bytes in network byte order.  The record,
   which MUST be in the order defined here, is:

   o  An integer specifying how many port numbers are listed.  This
      value MUST be at least 1.

   o  An unordered set of two-byte integers specifying the TCP/UDP ports
      for which the key is valid.  To indicate that the key is valid for
      all ports on the host associated with the domain name, a single
      value of 0 MUST be used.

   o  An integer specifying the type of key.

   o  A variable-length set of bytes with the key.

   [[ This will need a proper RRTYPE definiton.  That will be added
   later if this option is chosen. ]]

2.2.  Using a TXT Resource Record with a _TLSKEY Label Prefix

   A request for a TXT RR whose domain is the label _TLSKEY prepended to
   a domain name can be used to get the KEY associated with the domain
   name.  A query of this can return one or more records of the type
   TXT.

   The format of the TXT response is ASCII text.  The record, which MUST
   be in the order defined here, is:

   o  One or more instances of "port=" followed by an TCP/UDP port for
      which the key is valid (expressed as an integer), followd by ";".
      To indicate that the key is valid for all ports on the host
      associated with the domain name, a single "port=0;" MUST be used.

   o  The type of key, specified as "type=nn;" where "nn" is an integer
      defined below.

   o  "key=" followed by the set of bytes with the key; the bytes are
      encoded as lower-case hexadecimal.







Hoffman                 Expires February 5, 2011                [Page 3]


Internet-Draft            TLS Keys from the DNS              August 2010


2.3.  Types of Keys

   The initial list of key types is:

   o  0 - RSA

   o  1 - ECDSA using the P256 curve

   o  2 - ECDSA using the P384 curve

   o  3 - GOST

   [[ References are neede above. ]]


3.  Use of TLS Keys from the DNS in TLS

   In order to use one or more TLS keys obtained from the DNS, an
   application MUST assure that the keys were obtained using DNS
   protected by DNSSEC.  There may be other methods to securely obtain
   keys in DNS, but those methods are not covered by this document.

   An application that requests TLS keys using the method described in
   the previous section obtain zero or more keys.  If the application
   receives zero keys, it process TLS in the normal fashion.

   The application ignores the PKIX certificate received from the server
   and instead uses the key obtained from the DNS.  That is, the client
   does no processing on the PKIX certificate in the TLS Certificate
   message.  The application instead uses the key as the authenticator.

   If the application receives more than one key from the DNS query, it
   tries each key for which it understands while authenticating the TLS
   server.


4.  IANA Considerations

   [[ TBD.  Will include the registration for the TLSKEY RR if that is
   the style chosen, as well as a new registry for key types. ]]


5.  Security Considerations

   [[ TBD.  This section will need to describe, at least, the "attack"
   where a DNS administrator goes rogue and changes both the A and
   TLSKEY records for a domain name. ]]




Hoffman                 Expires February 5, 2011                [Page 4]


Internet-Draft            TLS Keys from the DNS              August 2010


6.  Normative References

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

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

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.


Author's Address

   Paul Hoffman
   VPN Consortium

   Email: paul.hoffman@vpnc.org
























Hoffman                 Expires February 5, 2011                [Page 5]