One document matched: draft-ogud-dane-vocabulary-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" ".//reference.RFC.2119.xml">
]>
<rfc category="info" docName="draft-ogud-dane-vocabulary-00" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<front>
<title abbrev="DANE common vocabulary: Defintion of Terms">
Harmonizing how applications specify DANE-like usage</title>
<author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
<organization>Shinkuro Inc.</organization>
<address>
<postal>
<street>4922 Fairmont Av, Suite 250</street>
<city>Bethesda</city>
<region>MD</region>
<code>20814</code>
<country>USA</country>
</postal>
<email>ogud@ogud.com</email>
</address>
</author>
<date day="10" month="June" year="2013" />
<area>Security</area>
<workgroup>DANE</workgroup>
<abstract>
<t>This document proposes a specific word usage for specifications of
DANE like technology by different protocols/services.
DANE is a method for specifying in DNS records acceptable
keys/certificates for application servers. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> DANE <xref target="RFC6698" /> is a powerful new way to
provide/amend how authentication/authorization/confidencialty of
a connection to a server can be protected by leveraging DNS
<xref target="RFC1034" />
and DNSSEC
<xref target="RFC4033" />
<xref target="RFC4034" />
<xref target="RFC4035" />
for the establishment of TLS connection <xref target="RFC5246"/>
<xref target="RFC6347" /> which in many cases uses PKIX <xref
target="RFC5280" />. All of these technologies are complicated.
People familiar with one or two are not necessarily familiar with
all the parts that needed to apply DANE like mechanism to other protocols.
</t>
<t> The goal of this document is two fold:
<list style="symbols">
<t>To provide an overview of the non protocol specific parts needed
to specify an DANE like addition. </t>
<t> To provide a common framework for such specifications making
it easy to review/compare the specifications. An important goal
is to allow the new specifications to avoid repeating
explanations and/or definitions. </t>
</list>
</t>
<t> This version of the document aims to hide complexity and focus
on generalities. This is done to make it easier for the reader to
decide if the terms here are of use and if it is worthwhile for
the DANE WG to adopt this document. Descriptions of complexities
can be added in later versions if the WG decides that is needed.
</t>
<t>
When below the notation "foo/bar" is used that is because the
editor is not sure if both apply or which one is more appropriate,
please advise.
</t>
<section title="Requirements notation">
<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
<xref target="RFC2119" />.
</t>
</section>
</section>
<section title="Proposed Terms">
<t> The terms below are being proposed to avoid confusion when
reading DANE like specifications for various application
protocols.
</t>
<t> At this point all the terms below are proposals and better terms
are welcome. </t>
<section title="DNS Navigation Records" anchor="DNS">
<t> DNS Navigation refers to any records used to traverse
the DNS tree to find the records requested. This includes
<list style="hanging" hangIndent="6">
<t hangText="NS records:">
that provide a referral to DNS servers for more specific
part of the name being looked up. Example: name server for
"example." will hand out a referral to server for
"bar.example." when asked about "foo.bar.example."
</t>
<t hangText="CNAME records:">
records that change the location of an record, this for all
practical purposes a pointer that only applies to that
specific name.
</t>
<t hangText="DNAME records:">
specify a rewrite rule for a name to a new name.
Example: "bar.example." DNAME "foo.example." means that
"www.bar.example." is to be looked up as
"www.foo.example". DNAME applies to names that are longer
than the name it, i.e. "bar.example." is not rewritten but
"www.bar.example." is
</t>
</list>
DANE specification explicitly requires all of these records to
be validated by DNSSEC.
See section <xref target="Integrity"/>
</t>
<t> While traversing the DNS tree other records like A and AAAA
are used but these records do not change the "navigation", these
records do not explicitly need to be protected as the data
retrieved from the addresses is expected to be protected.
</t>
</section>
<section title="DNS Integrity" anchor="Integrity">
<t>
DNSSEC defines a records and procedures to provide integrity and
authentication to data stored in DNS <xref target="RFC4034"
/>. The records used to
provide the keying information and chain of trust are DNSKEY, DS
records. NSEC/NSEC3 provide information about existence/non-
existence of the requested information. RRSIG provides a digital
signature for a RRset.</t>
<t>DNSSEC provides both Integrity and Authenticity i.e. it says the
records came from the right source and have not been changed.</t>
<t>Any DNS record that is DNS Integrity protected, will pass DNSSEC
validation for all DNS Navigation records leading to the name and the
record itself also passes DNSSEC validation.</t>
<t>In the case of CNAME and DNAME that go "sideways" i.e. to a
different branch of the DNS tree, both branches MUST be
validated.</t>
</section>
<section title="Service Specification Records" anchor="Service">
<t> Protocols have different ways to provide information about
where servers are located. Web servers are frequently specified
by name i.e. the "www" prefix. Email servers have a special RR type
(MX), Jabber uses SRV records, ENUM uses NAPTR records etc. and
there are also protocols that use a combination like S-NAPTR
a schema where NAPTR records are used to specify where to look
for SRV records.
</t>
<t> For a DANE like specification it has to be clear as what the
service specification records are and that these records use
requires DNS Integrity.
</t>
<t> NOTE: when NAPTR records as are used they should be the same
way as DNS Navigation records even though strictly speaking it
is the application that evaluates the NAPTR record. </t>
<t> NOTE: When there is a CNAME at the name service is expected
to be specified at, that can be either a DNS Navigation record or a
Service Specification Record. Protocol specification should
provide guidance on interpretation. </t>
</section>
<section title="Service Address Records" anchor="Addr">
<t>
This is where the address records used by the servers
reside, specifications SHOULD not make a difference between
what kind of address records are used.
</t>
<t>
In some cases the Service Specification records reside at the
same name as the Service Address records like for the original TLS
RFC, thus both kinds of records are covered by the same DNS
integrity rules.
</t>
</section>
<section title="Application Authentication Records" anchor="Auth">
<t> This term refers to the records that provide information
about what are acceptable keys or certificates for the servers to
offer.
</t>
<t> Application Authentication Records MUST be protected by DNS
Integrity and each protocol specification MUST explicitly state
where/how to look up the Authentication records.
</t>
<t> In some cases all the servers for a service will have the
same authentication information, in other cases it is going to be
on a server by server case. In the first case it is "natural" to
store the Authentication records "at" the Service
Specification records. In the second case it more natural to
store them "at" the Address Records.
In this context "at" means the authentication
records are stored at name that is an extension of the location
example: "_443._tcp.www.example.com" for <xref
target="RFC6698" />. It is possible that neither of these
locations is the right one and in that case the specification
MUST explicitly express rules as how to find the Authentication
Records.
</t>
<t>
Note: above that there is no a requirement that the Application
Address records be covered by DNS Integrity. This is because
when the Application Authentication records reside "at" the
address records, DNS Integrity is inherited. On the other hand
when when Application Authentication Records are stored
"at" the Service Specification Record, DNS Integrity for the
address records is optional, as any connection to
a bogus/wrong server should fail the Authentication tests
performed at connection time.
</t>
</section>
</section>
<section title="Example specifcation">
<t> This section is an short example for a protocol that is like SSH
<xref target="RFC4253"/> we will call this protocol HISS. This is
not an actual full specification, just here to give an idea of how
to go about extending DANE-like to a random protocol using the
terminology from this document.
</t>
<t>Location of HISS protocol DNS records:
<list style="hanging" hangIndent="6">
<t hangText="Service Specifcation Records:">
<vspace />
HISS uses address records as the service specification
record. This record MUST have "DNS Integrity" as explained in
RFC-to-be-this-document. CNAME is treated as a DNS
Navigation record.
</t>
<t hangText="Service Address Records:">
<vspace />
see: Service Specification Records.
</t>
<t hangText="Application Authentication Records:">
<vspace />
The protocol uses the DNS HISSFP that is stored at the same
name as the service is specified. The HISSFP record, if
present, takes precedence over keys stored in client cache.
</t>
</list>
</t>
<t> The HISS protocol and HISSFP DNS RR do not exist</t>
</section>
<section title="IANA considerations">
<t>None</t>
<t>[RFC Editor: Please remove this section before publication ]</t>
</section>
<section title="Security considerations">
<t> TBD</t>
</section>
<section title="Internationalizaiton Considerations">
<t> When selecting terms to use in standards documents it is
important to select works that do not confuse international
readers. This document goes out of its way in selecting English
terms that are dissimilar to avoid confusions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.6698'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.1034'?>
<?rfc include='reference.RFC.4033'?>
<?rfc include='reference.RFC.4034'?>
<?rfc include='reference.RFC.4035'?>
<?rfc include='reference.RFC.4253'?>
<?rfc include='reference.RFC.5246'?>
<?rfc include='reference.RFC.5280'?>
<?rfc include='reference.RFC.6347'?>
</references>
<section title="Document history">
<t>[RFC Editor: Please remove this section before publication ]</t>
<t> 00 Initial version </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:45:55 |