Internet DRAFT - draft-hoffman-tls-keys-from-dns
draft-hoffman-tls-keys-from-dns
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]
