Confirming the Certificate structure in TLS with Secure DNS
draft-josefsson-keyassure-tls-00

Abstract

TLS supports X.509 and OpenPGP certificate based mechanisms to authenticate a server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. Instead of trusting a certificate authority to have made this association correctly, and an X.509/OpenPGP implementation to validate that properly, the user might instead trust the authoritative DNS server for the domain name to make that association. This document describes how to use secure DNS to associate the certificate chain transferred by TLS with the intended domain name.

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 24, 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.

Table of Contents

1.  Introduction and Background
2.  The TLSCERT Certificate Type of the CERT RR
3.  IANA Considerations
4.  Acknowledgements
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Author's Address

1.  Introduction and Background

This document provides Transport Layer Security (TLS) (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] clients with an alternative way to authenticate the binding between the server's certificate and the domain name expected by the user.

TLS transfers the certificate from the server to the client using the Certificate structure, see section 7.4.2 of RFC 5246. We treat this structure as an opaque value, which results in that we support both X.509 and OpenPGP certificates directly.

Normally the binding between certificate and domain name is verified by using the normal PKIX (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) [RFC5280] or OpenPGP (Mavrogiannopoulos, N., “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication,” November 2007.) [RFC5081] validation algorithm, possibly together with an application protocol profile. A good overview of the current state is given by [I‑D.saintandre‑tls‑server‑id‑check] (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security,” August 2010.).

This document specify a way to directly authenticate the server certificate provided by a TLS server using DNSSEC (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) [RFC4033] using the CERT record (Josefsson, S., “Storing Certificates in the Domain Name System (DNS),” March 2006.) [RFC4398]. We specify a new CERT RR type to hold a hash of the Certificate structure sent by a TLS server to a client.

2.  The TLSCERT Certificate Type of the CERT RR

The CERT RR [RFC4398] allows expansion by defining new certificate types. The new certificate type "TLSCERT" is defined here. A query on a domain name for the CERT RR may return records of the type CERT, and zero or more of those CERT responses can be of type TLSCERT.

The format of the TLSCERT certificate type is binary. The record contains the SHA-256 (National Institute of Standards and Technology, “Secure Hash Standard,” August 2002.) [FIPS.180‑2.2002] hash of the Certificate structure as transferred from the TLS server to the client, including the length field.

[[Rationale: Use of the SHA-256 provides an yet unbroken hash of the data, and stronger hashes are of questionable utility with this method given that Secure DNS normally has other weaker parts due to performance reasons. Of course this approach is open for discussion.]]

The protocol (TCP or UDP) and port number is specified as part of the resource domain name as follows:

_443._tcp.example.com. IN CERT TLSCERT 0 0
                       IN1eoUHi9eb9nkCeROH5FmkdTKXQ/hmOM0mXjC2LM/I=
_5060._udp.example.com. IN CERT TLSCERT 0 0
                       R4UWsL/fwtOZp62gFHspEQY5v8iczDI20ZBOwMBQ1Hw=

[[Rationale: Letting the protocol and port number be part of the owner name reduces transfer sizes of the CERT record in situations where there would otherwise be multiple CERT records for unrelated services on the same domain name.]]

3.  IANA Considerations

The IANA is requested to register and allocate a number for a new CERT RR certificate type TLSCERT.

4.  Acknowledgements

Inspiration for this solution was drawn on earlier works in this area. Further, text were borrowed from draft-hoffman-keys-linkage-from-dns-00.

5.  Security Considerations

TBW

6.  References

6.1. Normative References

6.2. Informative References

Author's Address