idnits 2.17.1 draft-josefsson-keyassure-tls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 23, 2010) is 4988 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5081 (Obsoleted by RFC 6091) == Outdated reference: A later version (-14) exists of draft-saintandre-tls-server-id-check-09 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft SJD AB 4 Intended status: Standards Track August 23, 2010 5 Expires: February 24, 2011 7 Confirming the Certificate structure in TLS with Secure DNS 8 draft-josefsson-keyassure-tls-00 10 Abstract 12 TLS supports X.509 and OpenPGP certificate based mechanisms to 13 authenticate a server. Users want their applications to verify that 14 the certificate provided by the TLS server is in fact associated with 15 the domain name they expect. Instead of trusting a certificate 16 authority to have made this association correctly, and an X.509/ 17 OpenPGP implementation to validate that properly, the user might 18 instead trust the authoritative DNS server for the domain name to 19 make that association. This document describes how to use secure DNS 20 to associate the certificate chain transferred by TLS with the 21 intended domain name. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 24, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Background . . . . . . . . . . . . . . . . . . 3 58 2. The TLSCERT Certificate Type of the CERT RR . . . . . . . . . . 3 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 64 6.2. Informative References . . . . . . . . . . . . . . . . . . 4 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction and Background 69 This document provides Transport Layer Security (TLS) [RFC5246] 70 clients with an alternative way to authenticate the binding between 71 the server's certificate and the domain name expected by the user. 73 TLS transfers the certificate from the server to the client using the 74 Certificate structure, see section 7.4.2 of RFC 5246. We treat this 75 structure as an opaque value, which results in that we support both 76 X.509 and OpenPGP certificates directly. 78 Normally the binding between certificate and domain name is verified 79 by using the normal PKIX [RFC5280] or OpenPGP [RFC5081] validation 80 algorithm, possibly together with an application protocol profile. A 81 good overview of the current state is given by 82 [I-D.saintandre-tls-server-id-check]. 84 This document specify a way to directly authenticate the server 85 certificate provided by a TLS server using DNSSEC [RFC4033] using the 86 CERT record [RFC4398]. We specify a new CERT RR type to hold a hash 87 of the Certificate structure sent by a TLS server to a client. 89 2. The TLSCERT Certificate Type of the CERT RR 91 The CERT RR [RFC4398] allows expansion by defining new certificate 92 types. The new certificate type "TLSCERT" is defined here. A query 93 on a domain name for the CERT RR may return records of the type CERT, 94 and zero or more of those CERT responses can be of type TLSCERT. 96 The format of the TLSCERT certificate type is binary. The record 97 contains the SHA-256 [FIPS.180-2.2002] hash of the Certificate 98 structure as transferred from the TLS server to the client, including 99 the length field. 101 [[Rationale: Use of the SHA-256 provides an yet unbroken hash of the 102 data, and stronger hashes are of questionable utility with this 103 method given that Secure DNS normally has other weaker parts due to 104 performance reasons. Of course this approach is open for 105 discussion.]] 107 The protocol (TCP or UDP) and port number is specified as part of the 108 resource domain name as follows: 110 _443._tcp.example.com. IN CERT TLSCERT 0 0 111 IN1eoUHi9eb9nkCeROH5FmkdTKXQ/hmOM0mXjC2LM/I= 112 _5060._udp.example.com. IN CERT TLSCERT 0 0 113 R4UWsL/fwtOZp62gFHspEQY5v8iczDI20ZBOwMBQ1Hw= 115 [[Rationale: Letting the protocol and port number be part of the 116 owner name reduces transfer sizes of the CERT record in situations 117 where there would otherwise be multiple CERT records for unrelated 118 services on the same domain name.]] 120 3. IANA Considerations 122 The IANA is requested to register and allocate a number for a new 123 CERT RR certificate type TLSCERT. 125 4. Acknowledgements 127 Inspiration for this solution was drawn on earlier works in this 128 area. Further, text were borrowed from 129 draft-hoffman-keys-linkage-from-dns-00. 131 5. Security Considerations 133 TBW 135 6. References 137 6.1. Normative References 139 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 140 Rose, "DNS Security Introduction and Requirements", 141 RFC 4033, March 2005. 143 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 144 System (DNS)", RFC 4398, March 2006. 146 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 147 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 149 [FIPS.180-2.2002] 150 National Institute of Standards and Technology, "Secure 151 Hash Standard", FIPS PUB 180-2, August 2002, . 154 6.2. Informative References 156 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 157 Housley, R., and W. Polk, "Internet X.509 Public Key 158 Infrastructure Certificate and Certificate Revocation List 159 (CRL) Profile", RFC 5280, May 2008. 161 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 162 Layer Security (TLS) Authentication", RFC 5081, 163 November 2007. 165 [I-D.saintandre-tls-server-id-check] 166 Saint-Andre, P. and J. Hodges, "Representation and 167 Verification of Domain-Based Application Service Identity 168 in Certificates Used with Transport Layer Security", 169 draft-saintandre-tls-server-id-check-09 (work in 170 progress), August 2010. 172 Author's Address 174 Simon Josefsson 175 Simon Josefsson Datakonsult AB 176 Hagagatan 24 177 Stockholm 113 47 178 Sweden 180 Email: simon@josefsson.org 181 URI: http://josefsson.org/