One document matched: draft-ogud-dane-vocabulary-01.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-01"
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/>
<area>Security/ Apparea?? </area>
<workgroup>DANE</workgroup>
<abstract>
<t>There is no standard terminology as how to talk about use
of DNS in various application contexts, this document goal is
to facilitate creation of such a vocabulary/taxonomy. </t>
<t>This document started out as proposal for specific word
usage for specifications of adding DANE like technology by
different protocols/services.
DANE is a method for specifying in DNS records acceptable
keys/certificates for application servers. </t>
<t> The terms defined in this document should be applicable to
all uses of service specification that uses DNS records. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> DNS <xref target="RFC1034" /> is being used by many protocols
to express where services are located on the internet, today there
is no good way to express exactly what people have in mind when
specifying a new service/protocol exactly and in concise manner
how the service is looked up in the DNS.</t>
<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 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 three fold:
<list style="symbols">
<t>To provide common vocabulary for usage of DNS records in
service specification. </t>
<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>
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 reduce confusion when
reading protocol specifications, related to DNS and DANE, 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.
</t>
<t> 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 [RFC4033]. 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(s) that is DNS Integrity protected, will pass DNSSEC
validation for all DNS Navigation records leading to the name and the
record(s) also pass 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, this principle needs to be applied to all such
redirection.</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 SR 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. For all practical purposes NAPTR + SRV should
combined be treated as the Service Specification.
</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 a client supplies a string to the server as a
indicator of what service the the client wants, the string
supplied MAY depend on redirection in DNS navigation as well as
results of NAPTR records, etc. See section <xref target="Offered"/> </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 or are the same as the Service Address
records. Example: original TLS/DANE, 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/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
on 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 a rule 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>
<t> Note: When a Address record search starts with CNAME or DNAME, where
should the Authentication Records reside ? With redirection
record or with final address record ?
</t>
</section>
<section title="Offered Names" anchor="Offered">
<t>
When DNAME is used the name queried for is rewritten into a new
name. To disambiguate these cases following prefix terms are
defined. Similar rules apply NAPTR + SRV combinations.
It is important for many applications to be able to express what
name is presented to the service at connection time.
<list style="hanging" hangIndent="6">
<t hangText="Query:"> The name the application issues the query for
that RRset. </t>
<t hangText="Final:"> The name after all the indirection
records have been applied. </t>
<t hangText="SRV"> The name on the SRV record used. </t>
<t hangText="NAPTR"> The name on the first NAPTR record
used, prefix with Final if that is the one wanted.</t>
<t hangText="Intermediate"> A particular location in the
indirection chain. The specification needs to handle this
case if it ever occurs. NOTE: not sure this is
needed???</t>
</list>
</t>
</section>
</section>
<section title="DANE 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 Specification Records:">
<vspace />
HISS uses the address records as the service specification
record. This record MUST have "DNS Integrity" as explained in
RFC-to-be-this-document.
</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> Does this document, in a later version needs to address how to deal
with special cases resulting from IDN DNAME use? </t>
<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>
<t> 01 Updated version: added the section on Offered names,
expanded DNAME/CNAME text, added NAPTR and SRV
considerations. </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:43:50 |