One document matched: draft-josefsson-keyassure-tls-00.xml

<?xml version="1.0"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC4033 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4398 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4398.xml">
<!ENTITY RFC5246 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5280 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5081 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5081.xml">
<!ENTITY SHA256 SYSTEM
"http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.180-2.2002.xml">
<!ENTITY TLSIDCHECK SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-saintandre-tls-server-id-check-09.xml">
]>

<!-- Copyright (C) 2010 Simon Josefsson -->

<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<rfc category="info" ipr="trust200902"
     docName="draft-josefsson-keyassure-tls-00"
     category="std">

  <front>

    <title abbrev="DNSSEC TLS Certificate">
      Confirming the Certificate structure in TLS with Secure DNS
    </title>

    <author initials="S." surname="Josefsson" fullname="Simon Josefsson">
      <organization abbrev="SJD AB">
	Simon Josefsson Datakonsult AB
      </organization>
      <address>
       <postal>
           <street>Hagagatan 24</street>
           <city>Stockholm</city>
           <code>113 47</code>
           <country>Sweden</country>
       </postal>
	<email>simon@josefsson.org</email>
	<uri>http://josefsson.org/</uri>
      </address>
    </author>
    
    <date year="2010" month="August"/>

    <abstract>

      <t>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.</t>

    </abstract>

  </front>
  
  <middle>

    <section title="Introduction and Background">

      <t>This document provides <xref target="RFC5246">Transport Layer
	  Security (TLS)</xref> clients with an alternative way to
	authenticate the binding between the server's certificate
	and the domain name expected by the user.</t>

      <t>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.</t>

      <t>Normally the binding between certificate and domain name is
	verified by using the
	normal <xref target="RFC5280">PKIX</xref>
	or <xref target="RFC5081">OpenPGP</xref> validation algorithm,
	possibly together with an application protocol profile.  A
	good overview of the current state is given by
	<xref target="I-D.saintandre-tls-server-id-check"/>.</t>

      <t>This document specify a way to directly authenticate the
	server certificate provided by a TLS server
	using <xref target="RFC4033">DNSSEC</xref> using
	the <xref target="RFC4398">CERT record</xref>.  We specify a
	new CERT RR type to hold a hash of the Certificate structure
	sent by a TLS server to a client.</t>

    </section>

    <section title="The TLSCERT Certificate Type of the CERT RR">

      <t>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.</t>

      <t>The format of the TLSCERT certificate type is binary.  The
	record contains
	the <xref target="FIPS.180-2.2002">SHA-256</xref> hash of the
	Certificate structure as transferred from the TLS server to
	the client, including the length field.</t>

      <t>[[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.]]</t>

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

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

      <t>[[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.]]</t>

    </section>

    <section title="IANA Considerations">

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

    </section>

    <section title="Acknowledgements">

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

    </section>

    <section title="Security Considerations">

      <t>TBW</t>

    </section>

  </middle>

  <back>

    <references title="Normative References">

&RFC4033;
&RFC4398;
&RFC5246;
&SHA256;

    </references>

    <references title="Informative References">

&RFC5280;
&RFC5081;
&TLSIDCHECK;

    </references>

  </back>

</rfc>