<?xml version='1.0' encoding='ascii'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200902" docName="draft-petithuguenin-tram-stun-dane-04" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="DANE for STUN">Using DNS-based Authentication of Named Entities (DANE) to validate TLS certificates for the Session Traversal Utilities for NAT (STUN) protocol</title>
    <author initials="M." surname="Petit-Huguenin" fullname="Marc Petit-Huguenin">
      <organization>Impedance Mismatch</organization>
      <address>
        <email>marc@petit-huguenin.org</email>
      </address>
    </author>
    <author fullname="Olle E. Johansson" initials="O.E." surname="Johansson">
      <organization>Edvina AB</organization>
      <address>
        <postal>
          <street>Runbovaegen 10</street>
          <!--street>Runbov&#195;&#164;gen 10</street-->
          <city>Sollentuna</city>
          <code>SE-192 48</code>
          <country>SE</country>
        </postal>
        <email>oej@edvina.net</email>
      </address>
    </author>
    <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>
          <city>Research Triangle Park</city>
          <region>NC</region>
          <code>27709</code>
          <country>US</country>
        </postal>
        <email>gsalguei@cisco.com</email>
      </address>
    </author>
    <date year="2015"/>
    <area>TSV</area>
    <workgroup>TRAM</workgroup>
    <abstract>
      <t>This document defines how DNS-based Authentication of Named Entities (DANE) can be used to validate TLS certificates with the Session Traversal Utilities for NAT (STUN) protocol.  </t>
    </abstract>
  </front>
  <middle>
    <section anchor="section.intro" title="Introduction" toc="default">
      <t>This document defines how <xref target="RFC6698" pageno="false" format="default">DNS-based Authentication of Named Entities</xref> (DANE) can be used to validate TLS certificates with the <xref target="RFC5389" pageno="false" format="default">Session Traversal Utilities for NAT</xref> (STUN) protocol.  </t>
      <t><xref target="RFC5389" pageno="false" format="default">STUN</xref> uses <xref target="RFC5246" pageno="false" format="default">Transport Layer Security</xref> (TLS) as a secure transport and <xref target="RFC7350" pageno="false" format="default"/> subsequently added <xref target="RFC6347" pageno="false" format="default">Datagram Transport Layer Security</xref> (DTLS) as a secure transport more suited for the originally intended purpose of STUN, which is to support multimedia sessions.  Both transports require to have the certificate presented by the server validated following the rules established by <xref target="RFC2818" pageno="false" format="default"/>.  Additionally <xref target="RFC5389" pageno="false" format="default"/> provides rules on how to use <xref target="RFC2782" pageno="false" format="default">DNS SRV Resource Records</xref> to resolve a domain name to a list of host name for the purpose of load balancing and increased reliability.  These rules were subsequently enhanced to support <xref target="RFC5928" pageno="false" format="default">S-NAPTR Resource Records</xref> to add the possibility of selecting the preferred transport and redirect between domains.  </t>
      <t><xref target="RFC6698" pageno="false" format="default">DANE</xref> improves the mechanism established by <xref target="RFC2818" pageno="false" format="default"/> by enabling the administrators of domain names to specify the public keys (either in an <xref target="RFC5280" pageno="false" format="default">X.509 certificate or in a SubjectPublicKeyInfo structure</xref>) used by the secure servers in their domains.  The benefits of this approach encompass increasing flexibility, getting less reliance on trust anchors, enabling Perfect Forward Secrecy (PFS) and much more.  </t>
    </section>
    <section anchor="section.terminology" title="Terminology" toc="default">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119" pageno="false" format="default"/> when they appear in ALL CAPS.  When these words are not in ALL CAPS (such as "must" or "Must"), they have their usual English meanings, and are not to be interpreted as RFC 2119 key words.  </t>
      <t>"Source Domain" and "Host Name" are defined in <xref target="I-D.ietf-dane-srv" pageno="false" format="default"/>.</t>
    </section>
    <section anchor="section.operations" title="Operations" toc="default">
      <t>STUN clients that are conform with this specification, and that are using one or more DNS lookups to find the server, and that have established that all DNS Resource Records from the Source Domain to the Host Name are secure according to <xref target="RFC4033" pageno="false" format="default">DNSsec</xref> (i.e. that the AD bit is set in all the DNS answers), and that have selected a secure protocol (e.g. TLS or DTLS) MUST lookup for a TLSA Resource Record for the protocol, port and Host Name selected.  If the TLSA Resource Record is secure then the STUN client MUST use it to validate the certificate presented by the STUN server.  If there is no TLSA Resource Record or if the Resource Record is not secure, then the client MUST fallback to the validation process defined in <xref target="RFC5389" pageno="false" format="default"/> and <xref target="RFC7350" pageno="false" format="default"/>.  </t>
      <t>Note that only STUN Usages where the connection is the result of a DNS lookup are to be used with DANE which, for the list of STUN Usages listed in <xref target="RFC7350" pageno="false" format="default"/>, means these: </t>
      <t><list><t>NAT Discovery Usage</t><t>NAT Behavior Discovery Usage</t><t>TURN Usage</t></list> </t>
    </section>
    <!--section anchor="section.ref-impl" title="Implementation Status"> <t>[[Note to RFC Editor: Please remove this section and the reference to <xref target="RFC6982" /> before publication.]]</t> <t> This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in <xref target="RFC6982" />.  The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.  Please note that the listing of any individual implementation here does not imply endorsement by the IETF.  Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.  This is not intended as, and must not be construed to be, a catalog of available implementations or their features.  Readers are advised to note that other implementations may exist.  </t> <t> According to <xref target="RFC6982" />, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.  It is up to the individual working groups to use this information as they see fit".  </t> <section anchor="section.impl-status." title=""> <t> <list style="hanging"> <t hangText="Organization: "></t> <t hangText="Name: "></t> <t hangText="Description: "></t> <t hangText="Level of maturity: "></t> <t hangText="Coverage: "></t> <t hangText="Licensing: "></t> <t hangText="Implementation experience: "></t> <t hangText="Contact: "></t> </list> </t> </section> </section-->
    <section anchor="section.security" title="Security Considerations" toc="default">
      <t>Using DANE as (D)TLS certificate validation mechanism does not introduce any specific security considerations beyond those for STUN over TLS detailed in <xref target="RFC5389" pageno="false" format="default"/> and those for STUN over DTLS detailed in <xref target="RFC7350" pageno="false" format="default"/>.</t>
    </section>
    <section anchor="section.iana" title="IANA Considerations" toc="default">
      <t>This document has no IANA actions.</t>
    </section>
    <!--section anchor="section.acknowledgements" title="Acknowledgements"> <t>Thanks to  for the comments, suggestions, and questions that helped improve this document.</t> </section-->
  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner">
            <organization>Harvard University</organization>
            <address>
              <postal>
                <street>1350 Mass. Ave.</street>
                <street>Cambridge</street>
                <street>MA 02138</street>
              </postal>
              <phone>- +1 617 495 3864</phone>
              <email>sob@harvard.edu</email>
            </address>
          </author>
          <date year="1997" month="March"/>
          <area>General</area>
          <keyword>keyword</keyword>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  Authors who follow these guidelines should incorporate this phrase near the beginning of their document: <list><t>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.  </t></list></t>
            <t>Note that the force of these words is modified by the requirement level of the document in which they are used.  </t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/>
        <format type="HTML" octets="17970" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
        <format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
      </reference>
      <reference anchor="RFC2616">
        <front>
          <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
          <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
            <organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
            <address>
              <postal>
                <street>University of California, Irvine</street>
                <city>Irvine</city>
                <region>CA</region>
                <code>92697-3425</code>
              </postal>
              <facsimile>+1(949)824-1715</facsimile>
              <email>fielding@ics.uci.edu</email>
            </address>
          </author>
          <author initials="J." surname="Gettys" fullname="James Gettys">
            <organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>
            <address>
              <postal>
                <street>MIT Laboratory for Computer Science, NE43-356</street>
                <street>545 Technology Square</street>
                <city>Cambridge</city>
                <region>MA</region>
                <code>02139</code>
              </postal>
              <facsimile>+1(617)258-8682</facsimile>
              <email>jg@w3.org</email>
            </address>
          </author>
          <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
            <organization abbrev="Compaq">Compaq Computer Corporation</organization>
            <address>
              <postal>
                <street>Western Research Laboratory</street>
                <street>250 University Avenue</street>
                <city>Palo Alto</city>
                <region>CA</region>
                <code>94305</code>
              </postal>
              <email>mogul@wrl.dec.com</email>
            </address>
          </author>
          <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
            <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
            <address>
              <postal>
                <street>MIT Laboratory for Computer Science, NE43-356</street>
                <street>545 Technology Square</street>
                <city>Cambridge</city>
                <region>MA</region>
                <code>02139</code>
              </postal>
              <facsimile>+1(617)258-8682</facsimile>
              <email>frystyk@w3.org</email>
            </address>
          </author>
          <author initials="L." surname="Masinter" fullname="Larry Masinter">
            <organization abbrev="Xerox">Xerox Corporation</organization>
            <address>
              <postal>
                <street>MIT Laboratory for Computer Science, NE43-356</street>
                <street>3333 Coyote Hill Road</street>
                <city>Palo Alto</city>
                <region>CA</region>
                <code>94034</code>
              </postal>
              <email>masinter@parc.xerox.com</email>
            </address>
          </author>
          <author initials="P." surname="Leach" fullname="Paul J. Leach">
            <organization abbrev="Microsoft">Microsoft Corporation</organization>
            <address>
              <postal>
                <street>1 Microsoft Way</street>
                <city>Redmond</city>
                <region>WA</region>
                <code>98052</code>
              </postal>
              <email>paulle@microsoft.com</email>
            </address>
          </author>
          <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
            <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
            <address>
              <postal>
                <street>MIT Laboratory for Computer Science, NE43-356</street>
                <street>545 Technology Square</street>
                <city>Cambridge</city>
                <region>MA</region>
                <code>02139</code>
              </postal>
              <facsimile>+1(617)258-8682</facsimile>
              <email>timbl@w3.org</email>
            </address>
          </author>
          <date year="1999" month="June"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.  </t>
            <t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 .  </t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2616"/>
        <format type="TXT" octets="422317" target="http://www.rfc-editor.org/rfc/rfc2616.txt"/>
        <format type="PS" octets="5529857" target="http://www.rfc-editor.org/rfc/rfc2616.ps"/>
        <format type="PDF" octets="550558" target="http://www.rfc-editor.org/rfc/rfc2616.pdf"/>
        <format type="HTML" octets="637302" target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
        <format type="XML" octets="493420" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
      </reference>
      <reference anchor="RFC2782">
        <front>
          <title abbrev="DNS SRV RR">A DNS RR for specifying the location of services (DNS SRV)</title>
          <author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen">
            <organization>Troll Tech</organization>
            <address>
              <postal>
                <street>Waldemar Thranes gate 98B</street>
                <city>Oslo</city>
                <region/>
                <code>N-0175</code>
                <country>NO</country>
              </postal>
              <phone>+47 22 806390</phone>
              <facsimile>+47 22 806380</facsimile>
              <email>arnt@troll.no</email>
            </address>
          </author>
          <author initials="P." surname="Vixie" fullname="Paul Vixie">
            <organization>Internet Software Consortium</organization>
            <address>
              <postal>
                <street>950 Charter Street</street>
                <city>Redwood City</city>
                <region>CA</region>
                <code>94063</code>
                <country>US</country>
              </postal>
              <phone>+1 650 779 7001</phone>
            </address>
          </author>
          <author initials="L." surname="Esibov" fullname="Levon Esibov">
            <organization>Microsoft Corporation</organization>
            <address>
              <postal>
                <street>One Microsoft Way</street>
                <city>Redmond</city>
                <region>WA</region>
                <code>98052</code>
                <country>US</country>
              </postal>
              <email>levone@microsoft.com</email>
            </address>
          </author>
          <date year="2000" month="February"/>
          <abstract>
            <t>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2782"/>
        <format type="TXT" octets="24013" target="http://www.rfc-editor.org/rfc/rfc2782.txt"/>
      </reference>
      <reference anchor="RFC2818">
        <front>
          <title>HTTP Over TLS</title>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization/>
          </author>
          <date year="2000" month="May"/>
          <abstract>
            <t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2818"/>
        <format type="TXT" octets="15170" target="http://www.rfc-editor.org/rfc/rfc2818.txt"/>
      </reference>
      <reference anchor="RFC4033">
        <front>
          <title>DNS Security Introduction and Requirements</title>
          <author initials="R." surname="Arends" fullname="R. Arends">
            <organization/>
          </author>
          <author initials="R." surname="Austein" fullname="R. Austein">
            <organization/>
          </author>
          <author initials="M." surname="Larson" fullname="M. Larson">
            <organization/>
          </author>
          <author initials="D." surname="Massey" fullname="D. Massey">
            <organization/>
          </author>
          <author initials="S." surname="Rose" fullname="S. Rose">
            <organization/>
          </author>
          <date year="2005" month="March"/>
          <abstract>
            <t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System.  This document introduces these extensions and describes their capabilities and limitations.  This document also discusses the services that the DNS security extensions do and do not provide.  Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4033"/>
        <format type="TXT" octets="52445" target="http://www.rfc-editor.org/rfc/rfc4033.txt"/>
      </reference>
      <reference anchor="RFC5246">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
          <author initials="T." surname="Dierks" fullname="T. Dierks">
            <organization/>
          </author>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization/>
          </author>
          <date year="2008" month="August"/>
          <abstract>
            <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5246"/>
        <format type="TXT" octets="222395" target="http://www.rfc-editor.org/rfc/rfc5246.txt"/>
      </reference>
      <reference anchor="RFC5389">
        <front>
          <title>Session Traversal Utilities for NAT (STUN)</title>
          <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
            <organization/>
          </author>
          <author initials="R." surname="Mahy" fullname="R. Mahy">
            <organization/>
          </author>
          <author initials="P." surname="Matthews" fullname="P. Matthews">
            <organization/>
          </author>
          <author initials="D." surname="Wing" fullname="D. Wing">
            <organization/>
          </author>
          <date year="2008" month="October"/>
          <abstract>
            <t>Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.&lt;/t&gt;&lt;t&gt; STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.&lt;/t&gt;&lt;t&gt; This document obsoletes RFC 3489. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5389"/>
        <format type="TXT" octets="125650" target="http://www.rfc-editor.org/rfc/rfc5389.txt"/>
      </reference>
      <reference anchor="RFC5928">
        <front>
          <title>Traversal Using Relays around NAT (TURN) Resolution Mechanism</title>
          <author initials="M." surname="Petit-Huguenin" fullname="M. Petit-Huguenin">
            <organization/>
          </author>
          <date year="2010" month="August"/>
          <abstract>
            <t>This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5928"/>
        <format type="TXT" octets="23993" target="http://www.rfc-editor.org/rfc/rfc5928.txt"/>
      </reference>
      <reference anchor="RFC6347">
        <front>
          <title>Datagram Transport Layer Security Version 1.2</title>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization/>
          </author>
          <author initials="N." surname="Modadugu" fullname="N. Modadugu">
            <organization/>
          </author>
          <date year="2012" month="January"/>
          <abstract>
            <t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6347"/>
        <format type="TXT" octets="73546" target="http://www.rfc-editor.org/rfc/rfc6347.txt"/>
      </reference>
      <reference anchor="RFC6698">
        <front>
          <title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
          <author initials="P." surname="Hoffman" fullname="P. Hoffman">
            <organization/>
          </author>
          <author initials="J." surname="Schlyter" fullname="J. Schlyter">
            <organization/>
          </author>
          <date year="2012" month="August"/>
          <abstract>
            <t>Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used.  This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers.  This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6698"/>
        <format type="TXT" octets="84034" target="http://www.rfc-editor.org/rfc/rfc6698.txt"/>
      </reference>
      <reference anchor="RFC7350">
        <front>
          <title>Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)</title>
          <author initials="M." surname="Petit-Huguenin" fullname="M. Petit-Huguenin">
            <organization/>
          </author>
          <author initials="G." surname="Salgueiro" fullname="G. Salgueiro">
            <organization/>
          </author>
          <date year="2014" month="August"/>
          <abstract>
            <t>This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN).  It provides guidance on when and how to use DTLS with the currently standardized STUN usages.  It also specifies modifications to the STUN and Traversal Using Relay NAT (TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol.  This document updates RFCs 5389 and 5928.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7350"/>
        <format type="TXT" octets="27599" target="http://www.rfc-editor.org/rfc/rfc7350.txt"/>
      </reference>
      <reference anchor="I-D.ietf-dane-srv">
        <front>
          <title>Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records</title>
          <author initials="T" surname="Finch" fullname="Tony Finch">
            <organization/>
          </author>
          <author initials="M" surname="Miller" fullname="Matthew Miller">
            <organization/>
          </author>
          <author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
            <organization/>
          </author>
          <date month="July" day="23" year="2014"/>
          <abstract>
            <t>The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate, where the association is secured with DNSSEC.  However, application protocols that use SRV records (RFC 2782) to indirectly name the target server host names for a service domain cannot apply the rules from RFC 6698.  Therefore this document provides guidelines that enable such protocols to locate and use TLSA records.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-dane-srv-07"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-dane-srv-07.txt"/>
      </reference>
    </references>
    <references title="Informative References">
      <reference anchor="RFC5280">
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
          <author initials="D." surname="Cooper" fullname="D. Cooper">
            <organization/>
          </author>
          <author initials="S." surname="Santesson" fullname="S. Santesson">
            <organization/>
          </author>
          <author initials="S." surname="Farrell" fullname="S. Farrell">
            <organization/>
          </author>
          <author initials="S." surname="Boeyen" fullname="S. Boeyen">
            <organization/>
          </author>
          <author initials="R." surname="Housley" fullname="R. Housley">
            <organization/>
          </author>
          <author initials="W." surname="Polk" fullname="W. Polk">
            <organization/>
          </author>
          <date year="2008" month="May"/>
          <abstract>
            <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5280"/>
        <format type="TXT" octets="352580" target="http://www.rfc-editor.org/rfc/rfc5280.txt"/>
      </reference>
      <reference anchor="RFC7065">
        <front>
          <title>Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers</title>
          <author initials="M." surname="Petit-Huguenin" fullname="M. Petit-Huguenin">
            <organization/>
          </author>
          <author initials="S." surname="Nandakumar" fullname="S. Nandakumar">
            <organization/>
          </author>
          <author initials="G." surname="Salgueiro" fullname="G. Salgueiro">
            <organization/>
          </author>
          <author initials="P." surname="Jones" fullname="P. Jones">
            <organization/>
          </author>
          <date year="2013" month="November"/>
          <abstract>
            <t>This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol.  It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7065"/>
        <format type="TXT" octets="16143" target="http://www.rfc-editor.org/rfc/rfc7065.txt"/>
      </reference>
      <!--?rfc include="reference.RFC.6982" ?-->
    </references>
    <section anchor="appendix.examples" title="Examples" toc="default">
      <t>With the DNS RRs in <xref target="example.1" pageno="false" format="default"/> and an ordered TURN transport list of {DTLS, TLS, TCP, UDP}, a TURN client conform to this specification and using the <xref target="RFC7065" pageno="false" format="default">TURN URI</xref> "turns:example.com" will try first to connect to the TURN server at address 192.0.2.1:5389 using DTLS and using DANE to verify the certificate subsequently presented by the server.</t>
      <t>If this connection does not succeed, the client will then try to connect to the TURN server at 192.0.2.1:5000 but will not use DANE for the certificate verification even as a TLSA RR is available, because the DNSsec validation chain is broken in this case.</t>
      <t>Using a TURN URI of "turns:example.com;transport=udp" bypasses the NAPTR lookup, but at the expense of preventing the TLS fallback.</t>
      <figure anchor="example.1" title="" suppress-title="false" align="left" alt="" width="" height="">
        <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">example.com.
IN NAPTR 100 10 "" RELAY:turn.tls:turn.dtls "" example.net.
IN RRSIG NAPTR ...

_turns._tcp.example.com.
IN SRV   0 0 5000 a.example.net.

_turns._udp.example.com.
IN SRV   0 0 5349 a.example.net.
IN RRSIG SRV ...

example.net.
IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net.
IN NAPTR 100 10 "" RELAY:turn.udp:turn.dtls "" datagram.example.net.
IN RRSIG NAPTR ...

datagram.example.net.
IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.
IN NAPTR 100 10 S RELAY:turn.dtls "" _turns._udp.example.net.
IN RRSIG NAPTR ...

stream.example.net.
IN NAPTR 200 10 S RELAY:turn.tcp "" _turn._tcp.example.net.
IN NAPTR 200 10 S RELAY:turn.tls "" _turns._tcp.example.net.
IN RRSIG NAPTR ...

_turn._udp.example.net.
IN SRV   0 0 3478 a.example.net.

_turn._tcp.example.net.
IN SRV   0 0 5000 a.example.net.

_turns._udp.example.net.
IN SRV   0 0 5349 a.example.net.
IN RRSIG SRV ...

_turns._tcp.example.net.
IN SRV   0 0 5000 a.example.net.

a.example.net.
IN A     192.0.2.1
IN RRSIG A ...

_5389._udp.a.example.net.
IN TLSA ...
IN RRSIG TLSA ...

_5000._tcp.a.example.net.
IN TLSA ...
IN RRSIG TLSA ...
				</artwork>
      </figure>
    </section>
    <section title="Release notes" toc="default">
      <t>This section must be removed before publication as an RFC.</t>
      <section title="Modifications between draft-petithuguenin-tram-stun-dane-01 and draft-petithuguenin-tram-stun-dane-02" toc="default">
        <t><list style="symbols"><t>DANE can store public keys or certificates.</t></list> </t>
      </section>
      <section title="Modifications between draft-petithuguenin-tram-stun-dane-00 and draft-petithuguenin-tram-stun-dane-01" toc="default">
        <t><list style="symbols"><t>Change affiliation.</t><t>Update STUN-DTLS reference.</t><t>Nits</t></list> </t>
      </section>
    </section>
  </back>
</rfc>
