One document matched: draft-ogud-dane-vocabulary-02.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-02" 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: Definition 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/confidentiality 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> Number of RFC's in the past have tried to use consistent
terminology when specifying how to access services both in the
context of security <xref target="RFC6125"> TLS with X.509</xref>
and without security <xref target="RFC2782"/>. The terminology in this document is not
identical but concepts are similar. The hope is that once the
standard terminology is specified, as simple documents can provide
a mapping if one is needed.
</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 notation "foo/bar" is used below 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 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
<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 (SSR)" anchor="Service">
<t> Protocols have different ways to express servers.
<list style="symbols">
<t>Web servers are frequently specified by name i.e. the
"www" prefix, thus its service specification record is:
"address record stored at www.<domain>". </t>
<t> Email servers have a special RR type (MX): SRR= "MX record
at <domain>"), </t>
<t> Jabber uses SRV records: SSR="SRV record
at _xxmp-server.tcp.<domain>", </t>
<t>ENUM uses NAPTR records etc. </t>
<t>In addition 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>
</list>
</t>
<t> For a DANE like specification it has to be clear as what the
service specification records are and these records require 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>
<t> NOTE: when NAPTR records as are used they should be
treated 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 (SAR)" anchor="Addr">
<t>
These are the address records for the servers that offer the
service.
<!-- 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<xref target="RFC6698"/>,
thus both SSR and SAR records are covered by the same DNS integrity rule.
</t>
</section>
<section title="Application Authentication Records (AAR)" 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>
<t> Note: When a Address record search has a CNAME at or DNAME above, the
name queried, where should the Authentication Records reside ? With CNAME or with
final address record ?
</t>
</section>
<section title="Offered Name: Name used when indirection records
are used" anchor="Offered">
<t>
In many protocols one of the first items presented by the
application is a <name> that is "related to"/"derived from" the original
query name.
When DNAME is used the name queried for might be required to be rewritten into a new
name.</t>
<t> 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 by the application to the server at connection time.
<list style="hanging" hangIndent="6">
<t hangText="Query:"> The name the application issued the
query for to discover SSR/service. </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???ogud???</t>
</list>
</t>
</section>
</section>
<section title="Example specification">
<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 address records as the service specification
record. This record MUST have "DNS Integrity" as explained in
RFC-to-be-this-document. CNAME/DNAME are 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>
<t hangText="Offered Name">
<vspace/>
Not used.
</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> This documents goal is to improve specifications of
adding security via DANE technology to protocols, thus the
overwriting goal is to decrease confusion and increase clarity,
with the end goal of improving security.
This document does not specify a protocol. XX Needs more work XX
</t>
</section>
<section title="Internationalization 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>
<section title="Acknowledgements">
<t> Number of people have commented that this is interesting
work. Peter Saint-Andre tried to apply the terms to one of his
documents and provided many good suggestions. </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.2782"?>
<?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.6125'?>
<?rfc include='reference.RFC.6347'?>
</references>
<section title="Document history">
<t>[RFC Editor: Please remove this section before publication
]</t>
<t> 02 Textual improvements, applied comments from Peter
Saint-Andre. </t>
<t> 01 Added definition of offered names, expanded DNAME/CNAME
text added NAPTR and SRV. </t>
<t> 00 Initial version </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:44:11 |