rfc9102.original.xml | rfc9102.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="utf-8"?> | <?xml version="1.0" encoding="utf-8"?> | |||
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process | ||||
or - mmark.miek.nl" --> | <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> | |||
<rfc version="3" ipr="trust200902" docName="draft-dukhovni-tls-dnssec-chain-08" | ||||
submissionType="independent" category="exp" xml:lang="en" xmlns:xi="http://www.w | <rfc version="3" ipr="trust200902" docName="draft-dukhovni-tls-dnssec-chain-08" | |||
3.org/2001/XInclude"> | number="9102" submissionType="independent" category="exp" updates="" obsoletes=" | |||
" tocInclude="true" symRefs="true" sortRefs="true" xml:lang="en" xmlns:xi="http: | ||||
//www.w3.org/2001/XInclude"> | ||||
<front> | <front> | |||
<title abbrev="tls-dnssec-chain">TLS DNSSEC Chain Extension</title><seriesInfo v | <title abbrev="TLS DNSSEC Chain">TLS DNSSEC Chain Extension</title> | |||
alue="draft-dukhovni-tls-dnssec-chain-08" stream="independent" status="experimen | <seriesInfo name="RFC" value="9102"/> | |||
tal" name="Internet-Draft"></seriesInfo> | <author initials="V." surname="Dukhovni" fullname="Viktor Dukhovni"> | |||
<author initials="V." surname="Dukhovni" fullname="Viktor Dukhovni"><organizatio | <organization>Two Sigma</organization><address><postal> | |||
n>Two Sigma</organization><address><postal><street></street> | ||||
</postal><email>ietf-dane@dukhovni.org</email> | </postal><email>ietf-dane@dukhovni.org</email> | |||
</address></author> | </address></author> | |||
<author initials="S." surname="Huque" fullname="Shumon Huque"><organization>Sale | <author initials="S." surname="Huque" fullname="Shumon Huque"> | |||
sforce</organization><address><postal><street>415 Mission Street, 3rd Floor</str | <organization>Salesforce</organization> | |||
eet> | <address> | |||
<postal> | ||||
<extaddr>3rd Floor</extaddr> | ||||
<street>415 Mission Street</street> | ||||
<city>San Francisco</city> | <city>San Francisco</city> | |||
<code>CA 94105</code> | <region>CA</region> | |||
<code>94105</code> | ||||
<country>United States of America</country> | <country>United States of America</country> | |||
</postal><email>shuque@gmail.com</email> | </postal><email>shuque@gmail.com</email> | |||
</address></author> | </address></author> | |||
<author initials="W." surname="Toorop" fullname="Willem Toorop"><organization>NL net Labs</organization><address><postal><street>Science Park 400</street> | <author initials="W." surname="Toorop" fullname="Willem Toorop"><organization>NL net Labs</organization><address><postal><street>Science Park 400</street> | |||
<city>Amsterdam</city> | <city>Amsterdam</city> | |||
<code>1098 XH</code> | <code>1098 XH</code> | |||
<country>Netherlands</country> | <country>Netherlands</country> | |||
</postal><email>willem@nlnetlabs.nl</email> | </postal><email>willem@nlnetlabs.nl</email> | |||
</address></author> | </address></author> | |||
<author initials="P." surname="Wouters" fullname="Paul Wouters"><organization>Ai ven</organization><address><postal><street></street> | <author initials="P." surname="Wouters" fullname="Paul Wouters"><organization>Ai ven</organization><address><postal> | |||
<city>Toronto</city> | <city>Toronto</city> | |||
<country>Canada</country> | <country>Canada</country> | |||
</postal><email>paul.wouters@aiven.io</email> | </postal><email>paul.wouters@aiven.io</email> | |||
</address></author> | </address></author> | |||
<author initials="M." surname="Shore" fullname="Melinda Shore"><organization>Fas tly</organization><address><postal><street></street> | <author initials="M." surname="Shore" fullname="Melinda Shore"><organization>Fas tly</organization><address><postal> | |||
</postal><email>mshore@fastly.com</email> | </postal><email>mshore@fastly.com</email> | |||
</address></author> | </address></author> | |||
<date year="2021" month="June" day="10"></date> | <date year="2021" month="July" /> | |||
<area>Security</area> | ||||
<workgroup></workgroup> | ||||
<abstract> | <abstract> | |||
<t>This document describes an experimental TLS extension for in-band | <t>This document describes an experimental TLS extension for the in-band | |||
transport of the complete set of DNSSEC validatable records needed to | transport of the complete set of records that can be validated by DNSSEC and tha | |||
perform DANE authentication of a TLS server without the need to | t are needed to | |||
perform separate out-of-band DNS lookups. When the requisite DNS | perform DNS-Based Authentication of Named Entities (DANE) of a TLS server. This | |||
records do not exist, the extension conveys a validatable denial of | extension obviates the need to | |||
existence proof.</t> | perform separate, out-of-band DNS lookups. When the requisite DNS | |||
records do not exist, the extension conveys a denial-of-existence proof that can | ||||
be validated.</t> | ||||
<t>This experimental extension is developed outside the IETF and is | <t>This experimental extension is developed outside the IETF and is | |||
published here to guide implementation of the extension and to ensure | published here to guide implementation of the extension and to ensure | |||
interoperability among implementations.</t> | interoperability among implementations.</t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section anchor="introduction"><name>Introduction</name> | <section anchor="introduction"><name>Introduction</name> | |||
<t>This document describes an experimental TLS <xref target="RFC5246"></xref><xr | <t>This document describes an experimental TLS <xref target="RFC5246"></xref> <x | |||
ef target="RFC8446"></xref> | ref target="RFC8446"></xref> | |||
extension for in-band transport of the complete set of DNSSEC | extension for in-band transport of the complete set of resource records (RRs) va | |||
<xref target="RFC4033"></xref><xref target="RFC4034"></xref><xref target="RFC403 | lidated by DNSSEC <xref target="RFC4033"></xref> <xref target="RFC4034"></xref> | |||
5"></xref> validated Resource Records (RRs) that | <xref target="RFC4035"></xref>. This extension enables a TLS client to perform D | |||
enable a TLS client to perform DANE Authentication <xref target="RFC6698"></xref | ANE authentication <xref target="RFC6698"></xref> <xref target="RFC7671"></xref> | |||
><xref target="RFC7671"></xref> | ||||
of a TLS server without the need to perform out-of-band DNS lookups. | of a TLS server without the need to perform out-of-band DNS lookups. | |||
Retrieval of the required DNS records may be unavailable to the client | Retrieval of the required DNS records may be unavailable to the client | |||
<xref target="NLNETLABS"></xref>, or may incur undesirable additional latency.</ t> | <xref target="DISCOVERY"></xref> or may incur undesirable additional latency.</t > | |||
<t>The extension described here allows a TLS client to request that the | <t>The extension described here allows a TLS client to request that the | |||
TLS server return the DNSSEC authentication chain corresponding to | TLS server return the DNSSEC authentication chain corresponding to | |||
its DNSSEC-validated DANE TLSA Resource Record set (RRset), or | its DNSSEC-validated DANE TLSA resource record set (RRset) or | |||
authenticated denial of existence of such an RRset (as described in | authenticated denial of existence of such an RRset (as described in | |||
<xref target="denial_of_existence"></xref>). If the server supports this extensi on it | <xref target="denial_of_existence"></xref>). If the server supports this extensi on, it | |||
performs the appropriate DNS queries, builds the authentication | performs the appropriate DNS queries, builds the authentication | |||
chain, and returns it to the client. The server will typically use a | chain, and returns it to the client. The server will typically use a | |||
previously cached authentication chain, but it will need to rebuild | previously cached authentication chain, but it will need to rebuild | |||
it periodically as described in <xref target="sec_caching"></xref>. The client t hen | it periodically as described in <xref target="sec_caching"></xref>. The client t hen | |||
authenticates the chain using a preconfigured DNSSEC trust anchor.</t> | authenticates the chain using a preconfigured DNSSEC trust anchor.</t> | |||
<t>In the absence of TLSA records, this extension conveys the required | <t>In the absence of TLSA records, this extension conveys the required | |||
authenticated denial of existence. Such proofs are needed to securely | authenticated denial of existence. Such proofs are needed to securely | |||
signal that specified TLSA records are not available so that TLS clients | signal that specified TLSA records are not available so that TLS clients | |||
can safely fall back to Public-Key Infrastructure X.509 (PKIX, sometimes called | can safely fall back to authentication based on Public Key Infrastructure X.509 | |||
WebPKI) based authentication if allowed by local policy. These proofs | (PKIX, sometimes called | |||
WebPKI) if allowed by local policy. These proofs | ||||
are also needed to avoid downgrade from opportunistic authenticated TLS | are also needed to avoid downgrade from opportunistic authenticated TLS | |||
(when DANE TLSA records are present) to unauthenticated opportunistic TLS | (when DANE TLSA records are present) to unauthenticated opportunistic TLS | |||
(in the absence of DANE). Denial of existence records are also used by | (in the absence of DANE). Denial-of-existence records are also used by | |||
the TLS client to clear no longer relevant extension pins, as described in | the TLS client to clear extension pins that are no longer relevant, as described | |||
in | ||||
<xref target="pinning"></xref>.</t> | <xref target="pinning"></xref>.</t> | |||
<t>This extension supports DANE authentication of either X.509 | <t>This extension supports DANE authentication of either X.509 | |||
certificates or raw public keys as described in the DANE | certificates or raw public keys, as described in the DANE | |||
specification <xref target="RFC6698"></xref><xref target="RFC7671"></xref> and < | specification <xref target="RFC6698"></xref> <xref target="RFC7671"></xref> <xre | |||
xref target="RFC7250"></xref>.</t> | f target="RFC7250"></xref>.</t> | |||
<t>This extension also mitigates against an unknown key share (UKS) | <t>This extension also mitigates against an unknown key share (UKS) | |||
attack <xref target="I-D.barnes-dane-uks"></xref> when using raw public keys, si nce the | attack <xref target="I-D.barnes-dane-uks"></xref> when using raw public keys sin ce the | |||
server commits to its DNS name (normally found in its certificate) | server commits to its DNS name (normally found in its certificate) | |||
via the content of the returned TLSA RRset.</t> | via the content of the returned TLSA RRset.</t> | |||
<t>This experimental extension is developed outside the IETF and is | <t>This experimental extension is developed outside the IETF and is | |||
published here to guide implementation of the extension and to ensure | published here to guide implementation of the extension and to ensure | |||
interoperability among implementations.</t> | interoperability among implementations.</t> | |||
<section anchor="scope-of-the-experiment"><name>Scope of the experiment</name> | <section anchor="scope-of-the-experiment"><name>Scope of the Experiment</name> | |||
<t>The mechanism described in this document is intended to be used with | <t>The mechanism described in this document is intended to be used with | |||
applications on the wider internet. One application of TLS well | applications on the wider internet. One application of TLS well | |||
suited for the TLS DNSSEC Chain extension is DNS over TLS <xref target="RFC7858" ></xref>. | suited for the TLS DNSSEC Chain extension is DNS over TLS <xref target="RFC7858" ></xref>. | |||
In fact, one of the authentication methods for DNS over TLS <em>is</em> the | In fact, one of the authentication methods for DNS over TLS <em>is</em> the | |||
mechanism described in this document, as specified in Section 8.2.2 | mechanism described in this document, as specified in <xref target="RFC8310" sec | |||
of <xref target="RFC8310"></xref>.</t> | tion="8.2.2" sectionFormat="of"></xref>.</t> | |||
<t>The need for this mechanism when using DANE to authenticate a DNS over TLS | <t>The need for this mechanism when using DANE to authenticate a DNS-over-TLS | |||
resolver is obvious, since DNS may not be available to perform the | resolver is obvious, since DNS may not be available to perform the | |||
required DNS lookups. Other applications of TLS would benefit from | required DNS lookups. Other applications of TLS would benefit from | |||
using this mechanism as well. The client sides of those applications | using this mechanism as well. The client sides of those applications | |||
would not be required to be used on end-points with a working DNSSEC | would not be required to be used on endpoints with a working DNSSEC | |||
resolver in order for them to use DANE authentication of the TLS | resolver in order for them to use the DANE authentication of the TLS | |||
service. Therefore we invite other TLS services to try out this | service. Therefore, we invite other TLS services to try out this | |||
mechanism as well.</t> | mechanism as well.</t> | |||
<t>In the TLS working group, concerns have been raised that the pinning | <t>In the TLS Working Group, concerns have been raised that the pinning | |||
technique as described in <xref target="pinning"></xref> would complicate deploy ability | technique as described in <xref target="pinning"></xref> would complicate deploy ability | |||
of the TLS DNSSEC Chain extension. The goal of the experiment is to | of the TLS DNSSEC chain extension. The goal of the experiment is to | |||
study these complications in real world deployments. This experiment | study these complications in real-world deployments. This experiment | |||
hopefully will give the TLS working group some insight into whether | hopefully will give the TLS Working Group some insight into whether | |||
or not this is a problem.</t> | or not this is a problem.</t> | |||
<t>If the experiment is successful, it is expected that the findings of | <t>If the experiment is successful, it is expected that the findings of | |||
the experiment will result in an updated document for standards track | the experiment will result in an updated document for Standards Track | |||
approval.</t> | approval.</t> | |||
</section> | </section> | |||
<section anchor="requirements-notation"><name>Requirements Notation</name> | <section anchor="requirements-notation"><name>Requirements Notation</name> | |||
<t>The key words "MUST", "MUST NOT", "REQUIRED", | <t> | |||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU | |||
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and | IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | |||
"OPTIONAL" in this document are to be interpreted as described in | NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> | |||
BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and o | RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
nly when, they appear in | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | |||
all capitals, as shown here.</t> | be interpreted as | |||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> | ||||
when, and only when, they appear in all capitals, as shown here. | ||||
</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="dnssec-authentication-chain-extension"><name>DNSSEC Authenticat ion Chain Extension</name> | <section anchor="dnssec-authentication-chain-extension"><name>DNSSEC Authenticat ion Chain Extension</name> | |||
<section anchor="protocol-tls-1-2"><name>Protocol, TLS 1.2</name> | <section anchor="protocol-tls-1-2"><name>Protocol, TLS 1.2</name> | |||
<t>A client MAY include an extension of type <tt>dnssec_chain</tt> in the | <t>A client <bcp14>MAY</bcp14> include an extension of type <tt>dnssec_chain</tt > in the | |||
(extended) ClientHello. The <tt>extension_data</tt> field of this extension | (extended) ClientHello. The <tt>extension_data</tt> field of this extension | |||
consists of the server's 16-bit TCP port number in network | consists of the server's 16-bit TCP port number in network | |||
(big-endian) byte order. Clients sending this extension MUST also | (big-endian) byte order. Clients sending this extension <bcp14>MUST</bcp14> also | |||
send the Server Name Identification (SNI, <xref target="RFC6066"></xref>) | send the Server Name Identification (SNI) extension <xref target="RFC6066"></xre | |||
extension. Together, these make it possible for the TLS server to | f>. | |||
Together, these make it possible for the TLS server to | ||||
determine which authenticated TLSA RRset chain needs to be used for | determine which authenticated TLSA RRset chain needs to be used for | |||
the <tt>dnssec_chain</tt> extension.</t> | the <tt>dnssec_chain</tt> extension.</t> | |||
<t>When a server that implements (and is configured to enable the use | <t>When a server that implements (and is configured to enable the use | |||
of) this extension receives a <tt>dnssec_chain</tt> extension in the | of) this extension receives a <tt>dnssec_chain</tt> extension in the | |||
ClientHello, it MUST first check whether the requested TLSA RRset | ClientHello, it <bcp14>MUST</bcp14> first check whether the requested TLSA RRset | |||
(based on the port number in this extension and hostname in the SNI | (based on the port number in this extension and hostname in the SNI | |||
extension) is associated with the server. If the extension, the SNI | extension) is associated with the server. If the extension, the SNI | |||
hostname or the port number is unsupported, the server's extended | hostname, or the port number is unsupported, the server's extended | |||
ServerHello message MUST NOT include the <tt>dnssec_chain</tt> extension.</t> | ServerHello message <bcp14>MUST NOT</bcp14> include the <tt>dnssec_chain</tt> ex | |||
<t>Otherwise, the server's extended ServerHello message MUST contain a | tension.</t> | |||
<t>Otherwise, the server's extended ServerHello message <bcp14>MUST</bcp14> cont | ||||
ain a | ||||
serialized authentication chain using the format described below. If | serialized authentication chain using the format described below. If | |||
the server does not have access to the requested DNS chain - for | the server does not have access to the requested DNS chain -- for | |||
example due to a misconfiguration or expired chain - the server MUST | example, due to a misconfiguration or expired chain -- the server <bcp14>MUST</b | |||
cp14> | ||||
omit the extension rather than send an incomplete chain. Clients that | omit the extension rather than send an incomplete chain. Clients that | |||
are expecting this extension MUST interpret this as a downgrade | are expecting this extension <bcp14>MUST</bcp14> interpret this as a downgrade | |||
attack and MUST abort the TLS connection. Therefore, servers MUST send | attack and <bcp14>MUST</bcp14> abort the TLS connection. Therefore, servers <bc | |||
denial of existence proofs, unless, for the particular application | p14>MUST</bcp14> send | |||
denial-of-existence proofs unless, for the particular application | ||||
protocol or service, clients are expected to continue even in the | protocol or service, clients are expected to continue even in the | |||
absence of such a proof. As with all TLS extensions, if the server | absence of such a proof. As with all TLS extensions, if the server | |||
does not support this extension it will not return any authentication | does not support this extension, it will not return any authentication | |||
chain.</t> | chain.</t> | |||
<t>The set of supported combinations of port number and SNI name may be | <t>The set of supported combinations of a port number and SNI name may be | |||
configured explicitly by server administrators, or could be inferred | configured explicitly by server administrators or could be inferred | |||
from the available certificates combined with a list of supported ports. | from the available certificates combined with a list of supported ports. | |||
It is important to note that the client's notional port number may be | It is important to note that the client's notional port number may be | |||
different from the actual port on which the server is receiving | different from the actual port on which the server is receiving | |||
connections.</t> | connections.</t> | |||
<t>Differences between the client's notional port number and the actual | <t>Differences between the client's notional port number and the actual | |||
port at the server could be a result of intermediate systems performing | port at the server could be a result of intermediate systems performing | |||
network address translation, or perhaps a result of a redirect via HTTPS | network address translation or a result of a redirect via HTTPS | |||
or SVCB records (both defined in <xref target="I-D.ietf-dnsop-svcb-https"></xref >).</t> | or SVCB records (both defined in <xref target="I-D.ietf-dnsop-svcb-https"></xref >).</t> | |||
<t>Though a DNS zone's HTTPS or SVCB records may be signed, a client | <t>Though a DNS zone's HTTPS or SVCB records may be signed, a client | |||
using this protocol might not have direct access to a validating resolver, | using this protocol might not have direct access to a validating resolver | |||
and might not be able to check the authenticity of the target port number | and might not be able to check the authenticity of the target port number | |||
or hostname. In order to avoid downgrade attacks via forged DNS | or hostname. In order to avoid downgrade attacks via forged DNS | |||
records, the SNI name and port number inside the client extension MUST | records, the SNI name and port number inside the client extension <bcp14>MUST</b | |||
be based on the original SNI name and port and MUST NOT be taken from | cp14> | |||
the encountered HTTPS or SVCB record. The client supporting this document | be based on the original SNI name and port and <bcp14>MUST NOT</bcp14> be taken | |||
and HTTPS / SVCB records, MUST still use the HTTPS or SVCB records to | from | |||
the encountered HTTPS or SVCB record. | ||||
The client supporting this document | ||||
and HTTPS or SVCB records <bcp14>MUST</bcp14> still use the HTTPS or SVCB record | ||||
s to | ||||
select the target transport endpoint. Servers supporting this extension | select the target transport endpoint. Servers supporting this extension | |||
that are targets of HTTPS or SVCB records MUST be provisioned to process | that are targets of HTTPS or SVCB records <bcp14>MUST</bcp14> be provisioned to process | |||
client extensions based on the client's logical service endpoint's SNI | client extensions based on the client's logical service endpoint's SNI | |||
name and port as it is prior to HTTPS or SVCB indirection.</t> | name and port as it is prior to HTTPS or SVCB indirection.</t> | |||
</section> | </section> | |||
<section anchor="protocol-tls-1-3"><name>Protocol, TLS 1.3</name> | <section anchor="protocol-tls-1-3"><name>Protocol, TLS 1.3</name> | |||
<t>In TLS 1.3 <xref target="RFC8446"></xref>, when the server receives the <tt>d nssec_chain</tt> extension, | <t>In TLS 1.3 <xref target="RFC8446"></xref>, when the server receives the <tt>d nssec_chain</tt> extension, | |||
it adds its <tt>dnssec_chain</tt> extension to the extension block of the Certif icate | it adds its <tt>dnssec_chain</tt> extension to the extension block of the Certif icate | |||
message containing the end entity certificate being validated, rather than to | message containing the end-entity certificate being validated rather than to | |||
the extended ServerHello message.</t> | the extended ServerHello message.</t> | |||
<t>The extension protocol behavior otherwise follows that specified for | <t>The extension protocol behavior otherwise follows that specified for | |||
TLS version 1.2 <xref target="RFC5246"></xref>.</t> | TLS version 1.2 <xref target="RFC5246"></xref>.</t> | |||
</section> | </section> | |||
<section anchor="auth_chain_data"><name>DNSSEC Authentication Chain Data</name> | <section anchor="auth_chain_data"><name>DNSSEC Authentication Chain Data</name> | |||
<t>The <tt>extension_data</tt> field of the client's <tt>dnssec_chain</tt> exten sion | <t>The <tt>extension_data</tt> field of the client's <tt>dnssec_chain</tt> exten sion | |||
MUST contain the server's 16-bit TCP port number in network | <bcp14>MUST</bcp14> contain the server's 16-bit TCP port number in network | |||
(big-endian) byte order:</t> | (big-endian) byte order:</t> | |||
<sourcecode> struct { | ||||
<artwork> struct { | ||||
uint16 PortNumber; | uint16 PortNumber; | |||
} DnssecChainExtension; | } DnssecChainExtension; | |||
</artwork> | </sourcecode> | |||
<t>The <tt>extension_data</tt> field of the server's <tt>dnssec_chain</tt> exten sion | <t>The <tt>extension_data</tt> field of the server's <tt>dnssec_chain</tt> exten sion | |||
MUST contain a DNSSEC Authentication Chain encoded in the following | <bcp14>MUST</bcp14> contain a DNSSEC authentication chain encoded in the followi ng | |||
form:</t> | form:</t> | |||
<artwork> struct { | <sourcecode> struct { | |||
uint16 ExtSupportLifetime; | uint16 ExtSupportLifetime; | |||
opaque AuthenticationChain&lt;1..2^16-1&gt; | opaque AuthenticationChain<1..2^16-1&gt; | |||
} DnssecChainExtension; | } DnssecChainExtension; | |||
</artwork> | </sourcecode> | |||
<t>The ExtSupportLifetime value is the number of hours for which the TLS | <t>The ExtSupportLifetime value is the number of hours that the TLS | |||
server has committed itself to serving this extension. A value of | server has committed itself to serving this extension. A value of | |||
zero prohibits the client from unilaterally requiring ongoing use of | zero prohibits the client from unilaterally requiring ongoing use of | |||
the extension based on prior observation of its use (extension | the extension based on prior observation of its use (extension | |||
pinning). This is further described in <xref target="pinning"></xref>.</t> | pinning). This is further described in <xref target="pinning"></xref>.</t> | |||
<t>The AuthenticationChain is composed of a sequence of uncompressed | <t>The AuthenticationChain is composed of a sequence of uncompressed | |||
wire format DNS RRs (including all requisite RRSIG <xref target="RFC4034"></xref | wire format DNS RRs (including all requisite RRSIG RRs <xref target="RFC4034"></ | |||
> RRs) | xref>) | |||
in no particular order. The format of the Resource Record is | in no particular order. The format of the resource record is | |||
described in <xref target="RFC1035"></xref>, Section 3.2.1.</t> | described in <xref target="RFC1035" sectionFormat="comma" section="3.2.1"></xref | |||
>.</t> | ||||
<artwork> RR = { owner, type, class, TTL, RDATA length, RDATA } | <artwork> RR = { owner, type, class, TTL, RDATA length, RDATA } | |||
</artwork> | </artwork> | |||
<t>The order of returned RRs is unspecified and a TLS client MUST NOT | <t>The order of returned RRs is unspecified, and a TLS client <bcp14>MUST NOT</b cp14> | |||
assume any ordering of RRs.</t> | assume any ordering of RRs.</t> | |||
<t>Use of native DNS wire format records enables easier generation of | ||||
<t>Use of DNS wire format records enables easier generation of | ||||
the data structure on the server and easier verification of the data | the data structure on the server and easier verification of the data | |||
on client by means of existing DNS library functions.</t> | on the client by means of existing DNS library functions.</t> | |||
<t>The returned RRsets MUST contain either the TLSA RRset or else the | <t>The returned RRsets <bcp14>MUST</bcp14> contain either the TLSA RRset or the | |||
associated denial of existence proof of the configured (and requested) | associated denial-of-existence proof of the configured (and requested) | |||
SNI name and port. In either case, the chain of RRsets MUST be accompanied | SNI name and port. In either case, the chain of RRsets <bcp14>MUST</bcp14> be ac | |||
companied | ||||
by the full set of DNS records needed to authenticate the TLSA record set | by the full set of DNS records needed to authenticate the TLSA record set | |||
or its denial of existence up the DNS hierarchy to either the Root Zone | or its denial of existence up the DNS hierarchy to either the root zone | |||
or another trust anchor mutually configured by the TLS server and client.</t> | or another trust anchor mutually configured by the TLS server and client.</t> | |||
<t>When some subtree in the chain is subject to redirection via DNAME | <t>When some subtree in the chain is subject to redirection via DNAME | |||
records, the associated inferred CNAME records need not be included. | records, the associated inferred CNAME records need not be included. | |||
They can be inferred by the DNS validation code in the client. Any | They can be inferred by the DNS validation code in the client. Any | |||
applicable ordinary CNAME records that are not synthesized from DNAME | applicable ordinary CNAME records that are not synthesized from DNAME | |||
records MUST be included along with their RRSIGs.</t> | records <bcp14>MUST</bcp14> be included along with their RRSIGs.</t> | |||
<t>In case of a server-side DNS problem, servers may be unable to construct | <t>In case of a server-side DNS problem, servers may be unable to construct | |||
the authentication chain and would then have no choice but to omit the | the authentication chain and would then have no choice but to omit the | |||
extension.</t> | extension.</t> | |||
<t>In the case of a denial of existence response, the authentication | <t>In the case of a denial-of-existence response, the authentication | |||
chain MUST include all DNSSEC signed records from the trust-anchor | chain <bcp14>MUST</bcp14> include all DNSSEC-signed records, starting with those | |||
zone to a proof of either the non-existence of the (possibly redirected | from the trust anchor zone, that chain together to reach a proof of either:</t> | |||
via aliases) TLSA records or else of an insecure delegation above or | <ul empty="false"> | |||
at the (possibly redirected) owner name of the requested TLSA RRset.</t> | <li>the nonexistence of the TLSA records (possibly redirected | |||
via aliases) or</li><li>an insecure delegation above or | ||||
at the (possibly redirected) owner name of the requested TLSA RRset.</li></ul> | ||||
<t>Names that are aliased via CNAME and/or DNAME records may involve | <t>Names that are aliased via CNAME and/or DNAME records may involve | |||
multiple branches of the DNS tree. In this case, the authentication | multiple branches of the DNS tree. In this case, the authentication | |||
chain structure needs to include DS and DNSKEY record sets that cover | chain structure needs to include DS and DNSKEY record sets that cover | |||
all the necessary branches.</t> | all the necessary branches.</t> | |||
<t>The returned chain SHOULD also include the DNSKEY RRSets of all relevant | <t>The returned chain <bcp14>SHOULD</bcp14> also include the DNSKEY RRsets of al l relevant | |||
trust anchors (typically just the root DNS zone). Though the same trust | trust anchors (typically just the root DNS zone). Though the same trust | |||
anchors are presumably also preconfigured in the TLS client, including | anchors are presumably also preconfigured in the TLS client, including | |||
them in the response from the server permits TLS clients to use the | them in the response from the server permits TLS clients to use the | |||
automated trust anchor rollover mechanism defined in <xref target="RFC5011"></xr ef> to | automated trust anchor rollover mechanism defined in <xref target="RFC5011"></xr ef> to | |||
update their configured trust anchors.</t> | update their configured trust anchors.</t> | |||
<t>Barring prior knowledge of particular trust anchors that the server | <t>Barring prior knowledge of particular trust anchors that the server | |||
shares with its clients, the chain constructed by the server MUST be | shares with its clients, the chain constructed by the server <bcp14>MUST</bcp14> | |||
extended as close as possible to the root zone. Truncation of the chain | be | |||
extended as closely as possible to the root zone. Truncation of the chain | ||||
at some intermediate trust anchor is generally only appropriate inside | at some intermediate trust anchor is generally only appropriate inside | |||
private networks where all clients and the server are expected to be | private networks where all clients and the server are expected to be | |||
configured with DNS trust anchors for one or more non-root domains.</t> | configured with DNS trust anchors for one or more non-root domains.</t> | |||
<t>The following is an example of the records in the AuthenticationChain | <t>The following is an example of the records in the AuthenticationChain | |||
structure for the HTTPS server at <tt>www.example.com</tt>, where there are | structure for the HTTPS server at <tt>www.example.com</tt>, where there are | |||
zone cuts at <tt>com.</tt> and <tt>example.com.</tt> (record data are omitted he re | zone cuts at <tt>com</tt> and <tt>example.com</tt> (record data are omitted here | |||
for brevity):</t> | for brevity):</t> | |||
<artwork>_443._tcp.www.example.com. TLSA | <sourcecode type="dns-rr">_443._tcp.www.example.com. TLSA | |||
RRSIG(_443._tcp.www.example.com. TLSA) | RRSIG(_443._tcp.www.example.com. TLSA) | |||
example.com. DNSKEY | example.com. DNSKEY | |||
RRSIG(example.com. DNSKEY) | RRSIG(example.com. DNSKEY) | |||
example.com. DS | example.com. DS | |||
RRSIG(example.com. DS) | RRSIG(example.com. DS) | |||
com. DNSKEY | com. DNSKEY | |||
RRSIG(com. DNSKEY) | RRSIG(com. DNSKEY) | |||
com. DS | com. DS | |||
RRSIG(com. DS) | RRSIG(com. DS) | |||
. DNSKEY | . DNSKEY | |||
RRSIG(. DNSKEY) | RRSIG(. DNSKEY) | |||
</artwork> | </sourcecode> | |||
<t>The following is an example of denial of existence for a TLSA RRset | <t>The following is an example of denial of existence for a TLSA RRset | |||
at <tt>_443._tcp.www.example.com</tt>. The NSEC record in this example | at <tt>_443._tcp.www.example.com</tt>. The NSEC record in this example | |||
asserts the non-existence of both the requested RRset and any | asserts the nonexistence of both the requested RRset and any | |||
potentially relevant wildcard records.</t> | potentially relevant wildcard records.</t> | |||
<artwork>www.example.com. IN NSEC example.com. A NSEC RRSIG | <sourcecode type="dns-rr">www.example.com. IN NSEC example.com. A NSEC RRSIG | |||
RRSIG(www.example.com. NSEC) | RRSIG(www.example.com. NSEC) | |||
example.com. DNSKEY | example.com. DNSKEY | |||
RRSIG(example.com. DNSKEY) | RRSIG(example.com. DNSKEY) | |||
example.com. DS | example.com. DS | |||
RRSIG(example.com. DS) | RRSIG(example.com. DS) | |||
com. DNSKEY | com. DNSKEY | |||
RRSIG(com. DNSKEY) | RRSIG(com. DNSKEY) | |||
com. DS | com. DS | |||
RRSIG(com. DS) | RRSIG(com. DS) | |||
. DNSKEY | . DNSKEY | |||
RRSIG(. DNSKEY) | RRSIG(. DNSKEY) | |||
</artwork> | </sourcecode> | |||
<t>The following is an example of (hypothetical) insecure delegation of | <t>The following is an example of (hypothetical) insecure delegation of | |||
<tt>example.com</tt> from the <tt>.com</tt> zone. This example shows NSEC3 <xref | <tt>example.com</tt> from the <tt>.com</tt> zone. This example shows NSEC3 recor | |||
target="RFC5155"></xref> | ds <xref target="RFC5155"></xref> | |||
records with opt-out.</t> | with opt-out.</t> | |||
<artwork>; covers example.com | <sourcecode type="dns-rr">; covers example.com | |||
onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 - | onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 - | |||
onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG) | onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG) | |||
RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3) | RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3) | |||
; covers *.com | ; covers *.com | |||
3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 - | 3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 - | |||
3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG) | 3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG) | |||
RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3) | RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3) | |||
; closest-encloser "com" | ; closest-encloser "com" | |||
ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 - | ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 - | |||
ck0pojmg874ljref7efn8430qvit8bsm.com | ck0pojmg874ljref7efn8430qvit8bsm.com | |||
NS SOA RRSIG DNSKEY NSEC3PARAM) | NS SOA RRSIG DNSKEY NSEC3PARAM) | |||
RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3) | RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3) | |||
com. DNSKEY | com. DNSKEY | |||
RRSIG(com. DNSKEY) | RRSIG(com. DNSKEY) | |||
com. DS | com. DS | |||
RRSIG(com. DS) | RRSIG(com. DS) | |||
. DNSKEY | . DNSKEY | |||
RRSIG(. DNSKEY) | RRSIG(. DNSKEY) | |||
</artwork> | </sourcecode> | |||
<section anchor="denial_of_existence"><name>Authenticated Denial of Existence</n ame> | <section anchor="denial_of_existence"><name>Authenticated Denial of Existence</n ame> | |||
<t>TLS servers that support this extension and respond to a request | <t>TLS servers that support this extension and respond to a request | |||
containing this extension that do not have a signed TLSA record for the | containing this extension that do not have a signed TLSA record for the | |||
configured (and requested) SNI name and port MUST instead return a DNSSEC | configured (and requested) SNI name and port <bcp14>MUST</bcp14> instead return a DNSSEC | |||
chain that provides authenticated denial of existence for the configured | chain that provides authenticated denial of existence for the configured | |||
SNI name and port. A TLS client receiving proof of authenticated denial | SNI name and port. A TLS client receiving proof of authenticated denial | |||
of existence MUST use an alternative method to verify the TLS server | of existence <bcp14>MUST</bcp14> use an alternative method to verify the TLS ser ver | |||
identity or close the connection. Such an alternative could be the | identity or close the connection. Such an alternative could be the | |||
classic PKIX model of preinstalled root CA's.</t> | classic PKIX model of preinstalled root certificate authorities (CAs).</t> | |||
<t>Authenticated denial chains include NSEC or NSEC3 records that | <t>Authenticated denial chains include NSEC or NSEC3 records that | |||
demonstrate one of the following facts:</t> | demonstrate one of the following facts:</t> | |||
<ul> | <ul> | |||
<li><t>The TLSA record (after any DNSSEC validated alias redirection) | <li><t>The TLSA record (after any DNSSEC-validated alias redirection) | |||
does not exist.</t> | does not exist.</t> | |||
</li> | </li> | |||
<li><t>There is no signed delegation to a DNS zone which is either an | <li><t>There is no signed delegation to a DNS zone that is either an | |||
ancestor of, or the same as, the TLSA record name (after any | ancestor of or the same as the TLSA record name (after any | |||
DNSSEC validated alias redirection).</t> | DNSSEC-validated alias redirection).</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="construction"><name>Construction of Serialized Authentication C hains</name> | <section anchor="construction"><name>Construction of Serialized Authentication C hains</name> | |||
<t>This section describes a possible procedure for the server to use to | <t>This section describes a possible procedure for the server to use to | |||
build the serialized DNSSEC chain.</t> | build the serialized DNSSEC chain.</t> | |||
<t>When the goal is to perform DANE authentication <xref target="RFC6698"></xref ><xref target="RFC7671"></xref> | <t>When the goal is to perform DANE authentication <xref target="RFC6698"></xref > <xref target="RFC7671"></xref> | |||
of the server, the DNS record set to be serialized is a TLSA record | of the server, the DNS record set to be serialized is a TLSA record | |||
set corresponding to the server's domain name, protocol, and port | set corresponding to the server's domain name, protocol, and port | |||
number.</t> | number.</t> | |||
<t>The domain name of the server MUST be that included in the TLS | ||||
<t>The domain name of the server <bcp14>MUST</bcp14> be that included in the TLS | ||||
<tt>server_name</tt> (SNI) extension <xref target="RFC6066"></xref>. If the serv er | <tt>server_name</tt> (SNI) extension <xref target="RFC6066"></xref>. If the serv er | |||
does not recognize the SNI name as one if its own names, but wishes | does not recognize the SNI name as one of its own names but wishes | |||
to proceed with the handshake rather than to abort the connection, | to proceed with the handshake rather than abort the connection, | |||
the server MUST NOT send a <tt>dnssec_chain</tt> extension to the client.</t> | the server <bcp14>MUST NOT</bcp14> send a <tt>dnssec_chain</tt> extension to the | |||
<t>The name in client's SNI extension MUST NOT be CNAME-expanded by the | client.</t> | |||
server. The TLSA base domain (Section 3 of <xref target="RFC6698"></xref>) SHALL | <t>The name in the client's SNI extension <bcp14>MUST NOT</bcp14> be CNAME expan | |||
be the | ded by the | |||
hostname from the client's SNI extension and the guidance in Section | server. The TLSA base domain (<xref target="RFC6698" sectionFormat="of" section= | |||
7 of <xref target="RFC7671"></xref> does not apply. See <xref target="virtual"> | "3"></xref>) <bcp14>SHALL</bcp14> be the | |||
</xref> for further | hostname from the client's SNI extension, and the guidance in <xref target="RFC7 | |||
671" sectionFormat="of" section="7"></xref> does not apply. See <xref target="v | ||||
irtual"></xref> for further | ||||
discussion.</t> | discussion.</t> | |||
<t>The TLSA record to be queried is constructed by prepending | <t>The TLSA record to be queried is constructed by prepending | |||
underscore-prefixed port number and transport name labels to the domain | underscore-prefixed port number and transport name labels to the domain | |||
name as described in <xref target="RFC6698"></xref>. The port number is taken f rom the | name as described in <xref target="RFC6698"></xref>. The port number is taken f rom the | |||
client's <tt>dnssec_chain</tt> extension. The transport name is "tcp" for TLS | client's <tt>dnssec_chain</tt> extension. The transport name is "tcp" for TLS | |||
servers, and "udp" for DTLS servers. The port number label is the | servers and "udp" for DTLS servers. The port number label is the | |||
left-most label, followed by the transport name label, followed by the | leftmost label, followed by the transport name label, followed by the | |||
server domain name (from SNI).</t> | server domain name (from SNI).</t> | |||
<t>The components of the authentication chain are typically built by | <t>The components of the authentication chain are typically built by | |||
starting at the target record set and its corresponding RRSIG. Then | starting at the target record set and its corresponding RRSIG, then | |||
traversing the DNS tree upwards towards the trust anchor zone | traversing the DNS tree upwards towards the trust anchor zone | |||
(normally the DNS root). For each zone cut, the DNSKEY and DS RRsets | (normally the DNS root). For each zone cut, the DNSKEY, DS RRsets, | |||
and their signatures are added. However, see <xref target="auth_chain_data"></xr ef> for | and their signatures are added. However, see <xref target="auth_chain_data"></xr ef> for | |||
specific processing needed for aliases. If DNS response messages | specific processing needed for aliases. If DNS response messages | |||
contain any domain names utilizing name compression <xref target="RFC1035"></xre f>, then | contain any domain names utilizing name compression <xref target="RFC1035"></xre f>, then | |||
they MUST be uncompressed prior to inclusion in the chain.</t> | they <bcp14>MUST</bcp14> be uncompressed prior to inclusion in the chain.</t> | |||
<t>Implementations of EDNS Chain Query Requests as specified in | <t>Implementations of EDNS CHAIN query requests as specified in | |||
<xref target="RFC7901"></xref> may offer an easier way to obtain all of the chai n data | <xref target="RFC7901"></xref> may offer an easier way to obtain all of the chai n data | |||
in one transaction with an upstream DNSSEC aware recursive server.</t> | in one transaction with an upstream DNSSEC-aware recursive server.</t> | |||
</section> | </section> | |||
<section anchor="sec_caching"><name>Caching and Regeneration of the Authenticati on Chain</name> | <section anchor="sec_caching"><name>Caching and Regeneration of the Authenticati on Chain</name> | |||
<t>DNS records have Time To Live (TTL) parameters, and DNSSEC signatures | <t>DNS records have Time To Live (TTL) parameters, and DNSSEC signatures | |||
have validity periods (specifically signature expiration times). | have validity periods (specifically signature expiration times). | |||
After the TLS server constructs the serialized authentication chain, | After the TLS server constructs the serialized authentication chain, | |||
it SHOULD cache and reuse it in multiple TLS connection handshakes. | it <bcp14>SHOULD</bcp14> cache and reuse it in multiple TLS connection handshake | |||
However, it SHOULD refresh and rebuild the chain as TTL values require. | s. | |||
However, it <bcp14>SHOULD</bcp14> refresh and rebuild the chain as TTL values re | ||||
quire. | ||||
A server implementation could carefully track TTL parameters and requery | A server implementation could carefully track TTL parameters and requery | |||
component records in the chain correspondingly. Alternatively, it could | component records in the chain correspondingly. Alternatively, it could | |||
be configured to rebuild the entire chain at some predefined periodic | be configured to rebuild the entire chain at some predefined periodic | |||
interval that does not exceed the DNS TTLs of the component records in | interval that does not exceed the DNS TTLs of the component records in | |||
the chain. If a record in the chain has a very short TTL (eg 0 up to a | the chain. If a record in the chain has a very short TTL (e.g., 0 up to a | |||
few seconds), the server MAY decide to serve the authentication chain a | few seconds), the server <bcp14>MAY</bcp14> decide to serve the authentication c | |||
hain a | ||||
few seconds past the minimum TTL in the chain. This allows an | few seconds past the minimum TTL in the chain. This allows an | |||
implementation to dedicate a process or single thread to building the | implementation to dedicate a process or single thread to building the | |||
authentication chain and re-use it for more than a single | authentication chain and reuse it for more than a single | |||
waiting TLS client before needing to rebuild the authentication chain.</t> | waiting TLS client before needing to rebuild the authentication chain.</t> | |||
</section> | </section> | |||
<section anchor="sec_caching_exp"><name>Expired signatures in the Authentication | <section anchor="sec_caching_exp"><name>Expired Signatures in the Authentication | |||
Chain</name> | Chain</name> | |||
<t>A server MAY look at the signature expiration of RRSIG records. While | <t>A server <bcp14>MAY</bcp14> look at the signature expiration of RRSIG records | |||
. While | ||||
these should never expire before the TTL of the corresponding DNS record | these should never expire before the TTL of the corresponding DNS record | |||
is reached, if this situation is encountered nevertheless, the server | is reached, if this situation is nevertheless encountered, the server | |||
MAY lower the TTL to prevent serving expired RRSIGs if possible. If the | <bcp14>MAY</bcp14> lower the TTL to prevent serving expired RRSIGs if possible. | |||
signatures are already expired, the server MUST still include these records | If the | |||
into the authentication chain. This allows the TLS client to either support | signatures are already expired, the server <bcp14>MUST</bcp14> still include the | |||
a grace period for staleness, or allows the TLS client to give a detailed | se records | |||
error, either as log message or to a potential interactive user of the TLS | in the authentication chain. | |||
connection. The TLS client SHOULD handle expired RRSIGs similar to how it | ||||
This allows the TLS client to either support a grace period for staleness or giv | ||||
e a detailed error, either as a log | ||||
message or a message to a potential interactive user of the TLS connection. T | ||||
he TLS client <bcp14>SHOULD</bcp14> handle expired RRSIGs similarly to how it | ||||
handles expired PKIX certificates.</t> | handles expired PKIX certificates.</t> | |||
</section> | </section> | |||
<section anchor="sec_verification"><name>Verification</name> | <section anchor="sec_verification"><name>Verification</name> | |||
<t>A TLS client performing DANE based verification might not need to use | <t>A TLS client performing DANE-based verification might not need to use | |||
this extension. For example, the TLS client could perform native DNS | this extension. For example, the TLS client could perform DNS | |||
lookups and perform DANE verification without this extension. Or it | lookups and DANE verification without this extension, or it | |||
could fetch authentication chains via another protocol. If the TLS | could fetch authentication chains via another protocol. | |||
client already possesses a valid TLSA record, it MAY omit using this | ||||
extension. However, if it includes this extension, it MUST use the | If the TLS | |||
client already possesses a valid TLSA record, it <bcp14>MAY</bcp14> bypass use o | ||||
f this | ||||
extension. However, if it includes this extension, it <bcp14>MUST</bcp14> use th | ||||
e | ||||
TLS server reply to update the extension pinning status of the TLS | TLS server reply to update the extension pinning status of the TLS | |||
server's extension lifetime. See <xref target="pinning"></xref>.</t> | server's extension lifetime. See <xref target="pinning"></xref>.</t> | |||
<t>A TLS client making use of this specification, and which receives a | <t>A TLS client making use of this specification that receives a | |||
valid DNSSEC authentication chain extension from a TLS server, MUST use | valid DNSSEC authentication chain extension from a TLS server <bcp14>MUST</bcp14 | |||
> use | ||||
this information to perform DANE authentication of the TLS server. In | this information to perform DANE authentication of the TLS server. In | |||
order to perform the validation, it uses the mechanism specified by | order to perform the validation, it uses the mechanism specified by | |||
the DNSSEC protocol <xref target="RFC4035"></xref><xref target="RFC5155"></xref> . This mechanism is | the DNSSEC protocol <xref target="RFC4035"></xref> <xref target="RFC5155"></xref >. This mechanism is | |||
sometimes implemented in a DNSSEC validation engine or library.</t> | sometimes implemented in a DNSSEC validation engine or library.</t> | |||
<t>If the authentication chain validates, the TLS client then performs DANE | <t>If the authentication chain validates, the TLS client then performs DANE | |||
authentication of the server according to the DANE TLS protocol | authentication of the server according to the DANE TLS protocol | |||
<xref target="RFC6698"></xref><xref target="RFC7671"></xref>.</t> | <xref target="RFC6698"></xref> <xref target="RFC7671"></xref>.</t> | |||
<t>Clients MAY cache the server's validated TLSA RRset to amortize the | <t>Clients <bcp14>MAY</bcp14> cache the server's validated TLSA RRset to amortiz | |||
e the | ||||
cost of receiving and validating the chain over multiple connections. | cost of receiving and validating the chain over multiple connections. | |||
The period of such caching MUST NOT exceed the TTL associated with | The period of such caching <bcp14>MUST NOT</bcp14> exceed the TTL associated wit h | |||
those records. A client that possesses a validated and unexpired TLSA | those records. A client that possesses a validated and unexpired TLSA | |||
RRset or the full chain in its cache does not need to send the | RRset or the full chain in its cache does not need to send the | |||
<tt>dnssec_chain</tt> extension for subsequent connections to the same TLS | <tt>dnssec_chain</tt> extension for subsequent connections to the same TLS | |||
server. It can use the cached information to perform DANE | server. It can use the cached information to perform DANE | |||
authentication.</t> | authentication.</t> | |||
<t>Note that when a client and server perform TLS session resumption the | <t>Note that when a client and server perform TLS session resumption, the | |||
server sends no <tt>dnssec_chain</tt>. This is particularly clear with TLS | server sends no <tt>dnssec_chain</tt>. This is particularly clear with TLS | |||
1.3, where the certificate message to which the chain might be | 1.3, where the certificate message to which the chain might be | |||
attached is also not sent on resumption.</t> | attached is also not sent on resumption.</t> | |||
</section> | </section> | |||
<section anchor="pinning"><name>Extension Pinning</name> | <section anchor="pinning"><name>Extension Pinning</name> | |||
<t>TLS applications can be designed to unconditionally mandate this | <t>TLS applications can be designed to unconditionally mandate this | |||
extension. Such TLS clients requesting this extension would abort a | extension. Such TLS clients requesting this extension would abort a | |||
connection to a TLS server that does not respond with a validatable | connection to a TLS server that does not respond with an | |||
extension reply.</t> | extension reply that can be validated.</t> | |||
<t>However, in a mixed-use deployment of PKIX and DANE, there is the | <t>However, in a mixed-use deployment of PKIX and DANE, there is the | |||
possibility that the security of a TLS client is downgraded from DANE | possibility that the security of a TLS client is downgraded from DANE | |||
to PKIX. This can happen when a TLS client connection is | to PKIX. This can happen when a TLS client connection is | |||
intercepted and redirected to a rogue TLS server presenting a TLS | intercepted and redirected to a rogue TLS server presenting a TLS | |||
certificate that is considered valid from a PKIX point of view, but | certificate that is considered valid from a PKIX point of view but | |||
one that does not match the legitimate server's TLSA records. By | does not match the legitimate server's TLSA records. By | |||
omitting this extension, such a rogue TLS server could downgrade the | omitting this extension, such a rogue TLS server could downgrade the | |||
TLS client to validate the mis-issued certificate using only PKIX | TLS client to validate the mis-issued certificate using only PKIX | |||
and not via DANE, provided the TLS client is also not able to | and not via DANE, provided the TLS client is also not able to | |||
fetch the TLSA records directly from DNS.</t> | fetch the TLSA records directly from DNS.</t> | |||
<t>The ExtSupportLifetime element of the extension provides a | <t>The ExtSupportLifetime element of the extension provides a | |||
countermeasure against such downgrade attacks. Its value represents | countermeasure against such downgrade attacks. Its value represents | |||
the number of hours that the TLS server (or cluster of servers | the number of hours that the TLS server (or cluster of servers | |||
serving the same Server Name) commit to serving this extension in the | serving the same server name) commits to serving this extension in the | |||
future. This is referred to as the "pinning time" or "extension pin" | future. This is referred to as the "pinning time" or "extension pin" | |||
of the extension. A non-zero extension pin value received MUST ONLY | of the extension. A non-zero extension pin value received <bcp14>MUST</bcp14> O NLY | |||
be used if the extension also contains a valid TLSA authentication | be used if the extension also contains a valid TLSA authentication | |||
chain that matches the server's certificate chain (the server passes | chain that matches the server's certificate chain (the server passes | |||
DANE authentication based on the enclosed TLSA RRset).</t> | DANE authentication based on the enclosed TLSA RRset).</t> | |||
<t>Any existing extension pin for the server instance (name and port) | <t>Any existing extension pin for the server instance (name and port) | |||
MUST be cleared on receipt of a valid denial of existence for the | <bcp14>MUST</bcp14> be cleared on receipt of a valid denial of existence for the | |||
associated TLSA RRset. The same also applies if the client obtained | associated TLSA RRset. The same also applies if the client obtained | |||
the denial of existence proof via another method, such as through | the denial-of-existence proof via another method, such as through | |||
direct DNS queries. Based on the TLS client's local policy, it MAY | direct DNS queries. Based on the TLS client's local policy, it <bcp14>MAY</bcp1 | |||
then terminate the connection or MAY continue using PKIX based | 4> | |||
then terminate the connection or <bcp14>MAY</bcp14> continue using PKIX-based | ||||
server authentication.</t> | server authentication.</t> | |||
<t>Extension pins MUST also be cleared upon the completion of a DANE | <t>Extension pins <bcp14>MUST</bcp14> also be cleared upon the completion of a D | |||
authenticated handshake with a server that returns a <tt>dnssec_chain</tt> | ANE-authenticated handshake with a server that returns a <tt>dnssec_chain</tt> | |||
extension with a zero ExtSupportLifetime.</t> | extension with a zero ExtSupportLifetime.</t> | |||
<t>Upon completion of a full validated handshake with a server that | <t>Upon completion of a fully validated handshake with a server that | |||
returns a <tt>dnssec_chain</tt> extension with a non-zero ExtSupport lifetime, | returns a <tt>dnssec_chain</tt> extension with a non-zero ExtSupport lifetime, | |||
the client MUST update any existing pin lifetime for the service | the client <bcp14>MUST</bcp14> update any existing pin lifetime for the service | |||
(name and port) to a value that is no longer than that indicated by | (name and port) to a value that is not longer than that indicated by | |||
the server. The client MAY, subject to local policy, create a | the server. The client <bcp14>MAY</bcp14>, subject to local policy, create a | |||
previously non-existent pin, again for a lifetime that is not longer | previously nonexistent pin, again for a lifetime that is not longer | |||
than that indicated by the server.</t> | than that indicated by the server.</t> | |||
<t>The extension support lifetime is not constrained by any DNS TTLs or | <t>The extension support lifetime is not constrained by any DNS TTLs or | |||
RRSIG expirations in the returned chain. The extension support lifetime | RRSIG expirations in the returned chain. The extension support lifetime | |||
is the time for which the TLS server is committing itself to serve the | is the time for which the TLS server is committing itself to serve the | |||
extension; it is not a validity time for the returned chain data. | extension; it is not a validity time for the returned chain data. | |||
During this period the DNSSEC chain may be updated. Therefore, the | During this period, the DNSSEC chain may be updated. Therefore, the | |||
ExtSupportLifetime value is not constrained by any DNS TTLs or RRSIG | ExtSupportLifetime value is not constrained by any DNS TTLs or RRSIG | |||
expirations in the returned chain.</t> | expirations in the returned chain.</t> | |||
<t>Clients MAY implement support for a subset of DANE certificate | <t>Clients <bcp14>MAY</bcp14> implement support for a subset of DANE certificate | |||
usages. For example, clients may support only DANE-EE(3) and | usages. For example, clients may support only DANE-EE(3) and | |||
DANE-TA(2) <xref target="RFC7218"></xref>, only PKIX-EE(1) and PKIX-TA(0) | DANE-TA(2) <xref target="RFC7218"></xref>, only PKIX-EE(1) and PKIX-TA(0), | |||
or all four. Clients that implement DANE-EE(3) and DANE-TA(2) MUST | or all four. Clients that implement DANE-EE(3) and DANE-TA(2) <bcp14>MUST</bcp1 | |||
4> | ||||
implement the relevant updates in <xref target="RFC7671"></xref>.</t> | implement the relevant updates in <xref target="RFC7671"></xref>.</t> | |||
<t>For a non-zero saved value ("pin") of the ExtSupportLifetime element of the | <t>For a non-zero saved value ("pin") of the ExtSupportLifetime element of the | |||
extension, TLS clients that do not have a cached TLSA RRset with an | extension, TLS clients that do not have a cached TLSA RRset with an | |||
unexpired TTL MUST use the extension for the associated name and | unexpired TTL <bcp14>MUST</bcp14> use the extension for the associated name and | |||
port to obtain this information from the TLS server. This TLS client | port to obtain this information from the TLS server. | |||
then MUST require that the TLS server responds with this extension | ||||
that MUST contain a valid TLSA RRset or proof of non-existence of the | This TLS client | |||
TLSA RRset that covers the requested name and port. Note that a non-existence | then <bcp14>MUST</bcp14> require that the TLS server respond with this extension | |||
proof or proof of insecure delegation will clear the pin. The TLS client MUST | , | |||
which <bcp14>MUST</bcp14> contain a valid TLSA RRset or proof of nonexistence of | ||||
the | ||||
TLSA RRset that covers the requested name and port. Note that a nonexistence | ||||
proof or proof of insecure delegation will clear the pin. The TLS client <bcp14> | ||||
MUST</bcp14> | ||||
require this for as long as the time period specified by the pin value, | require this for as long as the time period specified by the pin value, | |||
independent of the DNS TTLs. If during this process, the TLS client fails | independent of the DNS TTLs. During this process, if the TLS client fails | |||
to receive this information, it MUST either abort the connection or delay | to receive this information, it <bcp14>MUST</bcp14> either abort the connection | |||
or delay | ||||
communication with the server via the TLS connection until it is able | communication with the server via the TLS connection until it is able | |||
to obtain valid TLSA records (or proof of non-existence) out of band, | to obtain valid TLSA records (or proof of nonexistence) out of band, | |||
such as via direct DNS lookups. If attempts to obtain the TLSA RRset | such as via direct DNS lookups. If attempts to obtain the TLSA RRset | |||
out of band fail, the client MUST abort the TLS connection. It MAY try | out of band fail, the client <bcp14>MUST</bcp14> abort the TLS connection. It <b | |||
a new TLS connection again, for example using an exponential back-off | cp14>MAY</bcp14> try | |||
timer, in an attempt to reach a different TLS server instance that does | a new TLS connection again (for example, using an exponential back-off | |||
timer) in an attempt to reach a different TLS server instance that does | ||||
properly serve the extension.</t> | properly serve the extension.</t> | |||
<t>A TLS client that has a cached validated TLSA RRset and a valid non-zero exte nsion | <t>A TLS client that has a cached validated TLSA RRset and a valid non-zero exte nsion | |||
pin time MAY still refrain from requesting the extension as long as it | pin time <bcp14>MAY</bcp14> still refrain from requesting the extension as long as it | |||
uses the cached TLSA RRset to authenticate the TLS server. This RRset | uses the cached TLSA RRset to authenticate the TLS server. This RRset | |||
MUST NOT be used beyond its received TTL. Once the TLSA RRset's | <bcp14>MUST NOT</bcp14> be used beyond its received TTL. Once the TLSA RRset's | |||
TTL has expired, the TLS client with a valid non-zero extension pin | TTL has expired, the TLS client with a valid non-zero extension pin | |||
time MUST request the extension and MUST abort the TLS connection if | time <bcp14>MUST</bcp14> request the extension and <bcp14>MUST</bcp14> abort the | |||
the server responds without the extension. A TLS client MAY attempt | TLS connection if | |||
the server responds without the extension. A TLS client <bcp14>MAY</bcp14> attem | ||||
pt | ||||
to obtain the valid TLSA RRset by some other means before | to obtain the valid TLSA RRset by some other means before | |||
initiating a new TLS connection.</t> | initiating a new TLS connection.</t> | |||
<t>Note that requiring the extension is NOT the same as requiring the | <t>Note that requiring the extension is NOT the same as requiring the | |||
use of DANE TLSA records or even DNSSEC. A DNS zone operator may at | use of DANE TLSA records or even DNSSEC. A DNS zone operator may at | |||
any time delete the TLSA records, or even remove the DS records to | any time delete the TLSA records or even remove the DS records to | |||
disable the secure delegation of the server's DNS zone. The TLS | disable the secure delegation of the server's DNS zone. The TLS | |||
server will, when it updates its cached TLSA authentication chain, | server will replace the chain with the corresponding denial-of-existence chain w | |||
replace the chain with the corresponding denial of existence chain. | hen it updates its cached TLSA authentication chain. | |||
The server's only obligation is continued support for this extension.</t> | The server's only obligation is continued support for this extension.</t> | |||
</section> | </section> | |||
<section anchor="sec_trustmaint"><name>Trust Anchor Maintenance</name> | <section anchor="sec_trustmaint"><name>Trust Anchor Maintenance</name> | |||
<t>The trust anchor may change periodically, e.g. when the operator of | <t>The trust anchor may change periodically, e.g., when the operator of | |||
the trust anchor zone performs a DNSSEC key rollover. TLS clients | the trust anchor zone performs a DNSSEC key rollover. TLS clients | |||
using this specification MUST implement a mechanism to keep their | using this specification <bcp14>MUST</bcp14> implement a mechanism to keep their | |||
trust anchors up to date. They could use the method defined in | trust anchors up to date. They could use the method defined in | |||
<xref target="RFC5011"></xref> to perform trust anchor updates inband in TLS, by tracking | <xref target="RFC5011"></xref> to perform trust anchor updates in-band in TLS by tracking | |||
the introduction of new keys seen in the trust anchor DNSKEY RRset. | the introduction of new keys seen in the trust anchor DNSKEY RRset. | |||
However, alternative mechanisms external to TLS may also be utilized. | However, alternative mechanisms external to TLS may also be utilized. | |||
Some operating systems may have a system-wide service to maintain and | Some operating systems may have a system-wide service to maintain and | |||
keep the root trust anchor up to date. In such cases, the TLS client | keep the root trust anchor up to date. In such cases, the TLS client | |||
application could simply reference that as its trust anchor, | application could simply reference that as its trust anchor, | |||
periodically checking whether it has changed. Some applications may | periodically checking whether it has changed. Some applications may | |||
prefer to implement trust anchor updates as part of their automated | prefer to implement trust anchor updates as part of their automated | |||
software updates.</t> | software updates.</t> | |||
</section> | </section> | |||
<section anchor="virtual"><name>Virtual Hosting</name> | <section anchor="virtual"><name>Virtual Hosting</name> | |||
<t>Delivery of application services is often provided by a third party | <t>Delivery of application services is often provided by a third party | |||
on behalf of the domain owner (hosting customer). Since the domain | on behalf of the domain owner (hosting customer). Since the domain | |||
owner may want to be able to move the service between providers, | owner may want to be able to move the service between providers, | |||
non-zero support lifetimes for this extension should only be enabled | non-zero support lifetimes for this extension should only be enabled | |||
by mutual agreement between the provider and domain owner.</t> | by mutual agreement between the provider and domain owner.</t> | |||
<t>When CNAME records are employed to redirect network connections to | <t>When CNAME records are employed to redirect network connections to | |||
the provider's network, as mentioned in <xref target="construction"></xref> the server | the provider's network, as mentioned in <xref target="construction"></xref>, the server | |||
uses the client's SNI hostname as the TLSA base domain without CNAME | uses the client's SNI hostname as the TLSA base domain without CNAME | |||
expansion. When the certificate chain for the service is managed by | expansion. When the certificate chain for the service is managed by | |||
the provider, it is impractical to coordinate certificate changes by | the provider, it is impractical to coordinate certificate changes by | |||
the provider with updates in the hosting customer's DNS. Therefore, | the provider with updates in the hosting customer's DNS. Therefore, | |||
the TLSA RRset for the hosted domain is best configured as a CNAME | the TLSA RRset for the hosted domain is best configured as a CNAME | |||
from the customer's domain to a TLSA RRset that is managed by the | from the customer's domain to a TLSA RRset that is managed by the | |||
provider as part of delivering the hosted service. For example:</t> | provider as part of delivering the hosted service. For example:</t> | |||
<artwork>; Customer DNS | <sourcecode type="dns-rr">; Customer DNS | |||
www.example.com. IN CNAME node1.provider.example. | www.example.com. IN CNAME node1.provider.example. | |||
_443._tcp.www.example.com. IN CNAME _dane443.node1.provider.example. | _443._tcp.www.example.com. IN CNAME _dane443.node1.provider.example. | |||
; Provider DNS | ; Provider DNS | |||
node1.provider.example. IN A 192.0.2.1 | node1.provider.example. IN A 192.0.2.1 | |||
_dane443.node1.provider.example. IN TLSA 1 1 1 ... | _dane443.node1.provider.example. IN TLSA 1 1 1 ... | |||
</artwork> | </sourcecode> | |||
<t>Clients that obtain TLSA records directly from DNS, bypassing this | <t>Clients that obtain TLSA records directly from DNS, bypassing this | |||
extension, may however perform CNAME-expansion as in Section 7 of | extension, may perform CNAME expansion as in <xref target="RFC7671" sectionForma | |||
<xref target="RFC7671"></xref>, and if TLSA records are associated with the | t="of" section="7"></xref>. If TLSA records are associated with the | |||
fully-expanded name, may use that name as the TLSA base domain and | fully expanded name, that name may be used as the TLSA base domain and | |||
SNI name for the TLS handshake.</t> | SNI name for the TLS handshake.</t> | |||
<t>To avoid confusion, it is RECOMMENDED that server operators not | <t>To avoid confusion, it is <bcp14>RECOMMENDED</bcp14> that server operators no t | |||
publish TLSA RRs (_port._tcp. + base domain) based on the expanded | publish TLSA RRs (_port._tcp. + base domain) based on the expanded | |||
CNAMEs used to locate their network addresses. Instead, the server | CNAMEs used to locate their network addresses. Instead, the server | |||
operator SHOULD publish TLSA RRs at an alternative DNS node (as in | operator <bcp14>SHOULD</bcp14> publish TLSA RRs at an alternative DNS node (as i n | |||
the example above), to which the hosting customer will publish a | the example above), to which the hosting customer will publish a | |||
CNAME alias. This results in all clients (whether they obtain TLSA | CNAME alias. This results in all clients (whether they obtain TLSA | |||
records from DNS directly, or employ this extension) seeing the same | records from DNS directly or employ this extension) seeing the same | |||
TLSA records and sending the same SNI name.</t> | TLSA records and sending the same SNI name.</t> | |||
</section> | </section> | |||
<section anchor="operational-considerations"><name>Operational Considerations</n ame> | <section anchor="operational-considerations"><name>Operational Considerations</n ame> | |||
<t>When DANE is being introduced incrementally into an existing PKIX | <t>When DANE is being introduced incrementally into an existing PKIX | |||
environment, there may be scenarios in which DANE authentication for | environment, there may be scenarios in which DANE authentication for | |||
a server fails but PKIX succeeds, or vice versa. What happens here | a server fails but PKIX succeeds, or vice versa. What happens here | |||
depends on TLS client policy. If DANE authentication fails, the | depends on TLS client policy. If DANE authentication fails, the | |||
client may decide to fall back to traditional PKIX authentication. In | client may decide to fall back to regular PKIX authentication. In | |||
order to do so efficiently within the same TLS handshake, the TLS | order to do so efficiently within the same TLS handshake, the TLS | |||
server needs to have provided the full X.509 certificate chain. When | server needs to have provided the full X.509 certificate chain. When | |||
TLS servers only support DANE-EE or DANE-TA modes, they have the | TLS servers only support DANE-EE or DANE-TA modes, they have the | |||
option to send a much smaller certificate chain: just the EE | option to send a much smaller certificate chain: just the EE | |||
certificate for the former, and a short certificate chain from the | certificate for the former and a short certificate chain from the | |||
DANE trust anchor to the EE certificate for the latter. If the TLS | DANE trust anchor to the EE certificate for the latter. If the TLS | |||
server supports both DANE and traditional PKIX, and wants to allow | server supports both DANE and regular PKIX and wants to allow | |||
efficient PKIX fallback within the same handshake, they should always | efficient PKIX fallback within the same handshake, they should always | |||
provide the full X.509 certificate chain.</t> | provide the full X.509 certificate chain.</t> | |||
<t>When a TLS server operator wishes to no longer deploy this extension, | <t>When a TLS server operator wishes to no longer deploy this extension, | |||
it must properly decommission its use. If a non-zero pin lifetime is | it must properly decommission its use. If a non-zero pin lifetime is | |||
presently advertised, it must first be changed to 0. The extension | presently advertised, it must first be changed to 0. The extension | |||
can be disabled once all previously advertised pin lifetimes have | can be disabled once all previously advertised pin lifetimes have | |||
expired. Removal of TLSA records or even DNSSEC signing of the zone | expired. Removal of TLSA records or even DNSSEC signing of the zone | |||
can be done at any time, but the server MUST still be able to return | can be done at any time, but the server <bcp14>MUST</bcp14> still be able to ret | |||
the associated denial of existence proofs to any clients that have | urn | |||
the associated denial-of-existence proofs to any clients that have | ||||
unexpired pins.</t> | unexpired pins.</t> | |||
<t>TLS clients MAY reduce the received extension pin value to a maximum | <t>TLS clients <bcp14>MAY</bcp14> reduce the received extension pin value to a m aximum | |||
set by local policy. This can mitigate a theoretical yet unlikely | set by local policy. This can mitigate a theoretical yet unlikely | |||
attack where a compromised TLS server is modified to advertise a pin | attack where a compromised TLS server is modified to advertise a pin | |||
value set to the maximum of 7 years. Care should be taken not to set | value set to the maximum of 7 years. Care should be taken not to set | |||
a local maximum that is too short as that would reduce the downgrade | a local maximum that is too short as that would reduce the downgrade | |||
attack protection that the extension pin offers.</t> | attack protection that the extension pin offers.</t> | |||
<t>If the hosting provider intends to use end-entity TLSA records | <t>If the hosting provider intends to use end-entity TLSA records | |||
(certificate usage PKIX-EE(1) or DANE-EE(3)) then the simplest | (certificate usage PKIX-EE(1) or DANE-EE(3)), then the simplest | |||
approach is to use the same key-pair for all the certificates at a | approach is to use the same key pair for all the certificates at a | |||
given hosting node, and publish "1 1 1" or "3 1 1" RRs matching the | given hosting node and publish "1 1 1" or "3 1 1" RRs matching the | |||
common public key. Since key rollover cannot be simultaneous across | common public key. Since key rollover cannot be simultaneous across | |||
multiple certificate updates, there will be times when multiple "1 1 | multiple certificate updates, there will be times when multiple "1 1 | |||
1" (or "3 1 1") records will be required to match all the extant | 1" (or "3 1 1") records will be required to match all the extant | |||
certificates. Multiple TLSA records are in any case needed a few | certificates. Multiple TLSA records are, in any case, needed a few | |||
TTLs before certificate updates as explained in Section 8 of | TTLs before certificate updates as explained in <xref target="RFC7671" sectionFo | |||
<xref target="RFC7671"></xref>.</t> | rmat="of" section="8"></xref>.</t> | |||
<t>If the hosting provider intends to use trust-anchor TLSA records | <t>If the hosting provider intends to use trust anchor TLSA records | |||
(certificate usage PKIX-TA(0) or DANE-TA(2)) then the same TLSA | (certificate usage PKIX-TA(0) or DANE-TA(2)), then the same TLSA | |||
record can match all end-entity certificates issues by the | record can match all end-entity certificates issues by the | |||
certification authority in question, and continues to work across | certification authority in question and continues to work across | |||
end-entity certificate updates, so long as the issuer certificate or | end-entity certificate updates so long as the issuer certificate or | |||
public keys remains unchanged. This can be easier to implement, at | public keys remain unchanged. This can be easier to implement at | |||
the cost of greater reliance on the security of the selected | the cost of greater reliance on the security of the selected | |||
certification authority.</t> | certification authority.</t> | |||
<t>The provider can of course publish separate TLSA records for each | <t>The provider can, of course, publish separate TLSA records for each | |||
customer, which increases the number of such RRsets that need to be | customer, which increases the number of such RRsets that need to be | |||
managed, but makes each one independent of the rest.</t> | managed but makes each one independent of the rest.</t> | |||
</section> | </section> | |||
<section anchor="security-considerations"><name>Security Considerations</name> | <section anchor="security-considerations"><name>Security Considerations</name> | |||
<t>The security considerations of the normatively referenced RFCs all | <t>The security considerations of the normatively referenced RFCs all | |||
pertain to this extension. Since the server is delivering a chain of | pertain to this extension. Since the server is delivering a chain of | |||
DNS records and signatures to the client, it MUST rebuild the chain in | DNS records and signatures to the client, it <bcp14>MUST</bcp14> rebuild the cha in in | |||
accordance with TTL and signature expiration of the chain components | accordance with TTL and signature expiration of the chain components | |||
as described in <xref target="sec_caching"></xref>. TLS clients need roughly ac curate | as described in <xref target="sec_caching"></xref>. TLS clients need roughly ac curate | |||
time in order to properly authenticate these signatures. This could be | time in order to properly authenticate these signatures. This could be | |||
achieved by running a time synchronization protocol like NTP <xref target="RFC59 05"></xref> | achieved by running a time synchronization protocol like NTP <xref target="RFC59 05"></xref> | |||
or SNTP <xref target="RFC5905"></xref>, which are already widely used today. TLS clients | or SNTP <xref target="RFC5905"></xref>, which are already widely used today. TLS clients | |||
MUST support a mechanism to track and roll over the trust anchor key, | <bcp14>MUST</bcp14> support a mechanism to track and roll over the trust anchor key | |||
or be able to avail themselves of a service that does this, as described | or be able to avail themselves of a service that does this, as described | |||
in <xref target="sec_trustmaint"></xref>. Security considerations related to ma ndating the | in <xref target="sec_trustmaint"></xref>. Security considerations related to ma ndating the | |||
use of this extension are described in <xref target="pinning"></xref>.</t> | use of this extension are described in <xref target="pinning"></xref>.</t> | |||
<t>The received DNSSEC chain could contain DNS RRs that are not related | <t>The received DNSSEC chain could contain DNS RRs that are not related | |||
to the TLSA verification of the intended DNS name. If such a unrelated | to the TLSA verification of the intended DNS name. If such an unrelated | |||
RR is not DNSSEC signed, it MUST be disgarded. If the unrelated RRset | RR is not DNSSEC signed, it <bcp14>MUST</bcp14> be discarded. If the unrelated R | |||
is DNSSEC signed, the TLS client MAY decide to add these RRsets and | Rset | |||
their DNSSEC signatures to its cache. It MAY even pass this data to the | is DNSSEC signed, the TLS client <bcp14>MAY</bcp14> decide to add these RRsets a | |||
local system resolver for caching outside the application. However, care | nd | |||
must be taken that caching these records could be used for timing and | their DNSSEC signatures to its cache. It <bcp14>MAY</bcp14> even pass this data | |||
to the | ||||
local system resolver for caching outside the application. | ||||
However, care | ||||
must be taken because caching these records could be used for timing and | ||||
caching attacks to de-anonymize the TLS client or its user. A TLS client | caching attacks to de-anonymize the TLS client or its user. A TLS client | |||
that wants to present the strongest anonymity protection to their users, | that wants to present the strongest anonymity protection to their users | |||
MUST refrain from using and caching all unrelated RRs.</t> | <bcp14>MUST</bcp14> refrain from using and caching all unrelated RRs.</t> | |||
</section> | </section> | |||
<section anchor="iana_requests"><name>IANA Considerations</name> | <section anchor="iana_requests"><name>IANA Considerations</name> | |||
<t>This document defines one new entry in the TLS ExtensionType Values | <t>IANA has made the following assignment in the "TLS ExtensionType Values" | |||
registry:</t> | registry:</t> | |||
<table> | <table> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="right">Value</th> | <th align="right">Value</th> | |||
<th>Extension Name</th> | <th>Extension Name</th> | |||
<th>TLS 1.3</th> | <th>TLS 1.3</th> | |||
<th>Recommended</th> | <th>Recommended</th> | |||
<th>Reference</th> | <th>Reference</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="right">TBD</td> | <td align="right">59</td> | |||
<td>dnssec_chain</td> | <td>dnssec_chain</td> | |||
<td>CH</td> | <td>CH</td> | |||
<td>No</td> | <td>No</td> | |||
<td>[this document]</td> | <td>RFC 9102</td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table></section> | </table></section> | |||
<section anchor="acknowledgments"><name>Acknowledgments</name> | ||||
<t>Many thanks to Adam Langley for laying the groundwork for this | ||||
extension in <xref target="I-D.agl-dane-serializechain"></xref>. The original id | ||||
ea is his | ||||
but our acknowledgment in no way implies his endorsement. This | ||||
document also benefited from discussions with and review from the | ||||
following people: Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, | ||||
Patrick McManus, Rick van Rein, Ilari Liusvaara, Eric Rescorla, Gowri | ||||
Visweswaran, Duane Wessels, Nico Williams, and Richard Barnes.</t> | ||||
</section> | ||||
</middle> | </middle> | |||
<back> | <back> | |||
<displayreference target="I-D.agl-dane-serializechain" to="SERIALIZECHAIN"/> | ||||
<displayreference target="I-D.barnes-dane-uks" to="DANE-UKS"/> | ||||
<displayreference target="I-D.ietf-dnsop-svcb-https" to="DNSOP-SVCB-HTTPS"/> | ||||
<references><name>References</name> | ||||
<references><name>Normative References</name> | <references><name>Normative References</name> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7218. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7218. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7671. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7671. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8310. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8310. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446. xml"/> | |||
</references> | </references> | |||
<references><name>Informative References</name> | <references><name>Informative References</name> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.a | ||||
gl-dane-serializechain.xml"/> | <!-- [I-D.agl-dane-serializechain] IESG state Expired --> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.b | ||||
arnes-dane-uks.xml"/> | <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.agl-dan | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i | e-serializechain.xml"/> | |||
etf-dnsop-svcb-https.xml"/> | ||||
<reference anchor="NLNETLABS" target="https://www.nlnetlabs.nl/downloads/publica | <!-- [I-D.barnes-dane-uks] IESG state Expired --> | |||
tions/os3-2015-rp2-xavier-torrent-gorjon.pdf"> | <reference anchor='I-D.barnes-dane-uks'> | |||
<front> | ||||
<title>Unknown Key-Share Attacks on DNS-Based Authentications of Named Entities | ||||
(DANE)</title> | ||||
<author initials='R' surname='Barnes' fullname='Richard Barnes'> | ||||
<organization /> | ||||
</author> | ||||
<author initials='M' surname='Thomson' fullname='Martin Thomson'> | ||||
<organization /> | ||||
</author> | ||||
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'> | ||||
<organization /> | ||||
</author> | ||||
<date month='October' day='9' year='2016' /> | ||||
</front> | ||||
<seriesInfo name='Internet-Draft' value='draft-barnes-dane-uks-00' /> | ||||
<format type='TXT' | ||||
target='http://www.ietf.org/internet-drafts/draft-barnes-dane-uks-00.txt | ||||
' /> | ||||
</reference> | ||||
<!-- [I-D.ietf-dnsop-svcb-https] IESG state I-D Exists --> | ||||
<reference anchor='I-D.ietf-dnsop-svcb-https'> | ||||
<front> | ||||
<title>Service Binding and Parameter Specification via the DNS (DNS SVCB and HTT | ||||
PS RRs)</title> | ||||
<author initials='B' surname='Schwartz' fullname='Benjamin Schwartz'> | ||||
<organization /> | ||||
</author> | ||||
<author initials='M' surname='Bishop' fullname='Mike Bishop'> | ||||
<organization /> | ||||
</author> | ||||
<author initials='E' surname='Nygren' fullname='Erik Nygren'> | ||||
<organization /> | ||||
</author> | ||||
<date year='2021' month='June' day='16' /> | ||||
</front> | ||||
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-svcb-https-06'/> | ||||
<format type='TXT' target='https://www.ietf.org/internet-drafts/draft-ietf-dnsop | ||||
-svcb-https-06.txt'/> | ||||
</reference> | ||||
<reference anchor="DISCOVERY" target="https://www.nlnetlabs.nl/downloads/publica | ||||
tions/os3-2015-rp2-xavier-torrent-gorjon.pdf"> | ||||
<front> | <front> | |||
<title>Discovery method for a DNSSEC validating stub resolver</title> | <title>Discovery method for a DNSSEC validating stub resolver</title> | |||
<author fullname="Xavier Torrent Gorjon" initials="X." surname="Gorjon"></au thor> | <author fullname="Xavier Torrent Gorjon" initials="X." surname="Gorjon"></au thor> | |||
<author fullname="Willem Toorop" initials="W." surname="Toorop"></author> | <author fullname="Willem Toorop" initials="W." surname="Toorop"></author> | |||
<date year="2015" month="July" day="14"></date> | <date year="2015" month="July" day="14"></date> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5011. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5011. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7901. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7901. xml"/> | |||
</references> | </references> | |||
</references> | ||||
<section anchor="test-vectors"><name>Test Vectors</name> | <section anchor="test-vectors"><name>Test Vectors</name> | |||
<t>The test vectors in this appendix are representations of the content | <t>The test vectors in this appendix are representations of the content | |||
of the "opaque AuthenticationChain" field in DNS presentation format. | of the "opaque AuthenticationChain" field in DNS presentation format and, except | |||
And except for the <tt>extension_data</tt> in <xref target="hex_dump"></xref>, d | for the <tt>extension_data</tt> in <xref target="hex_dump"></xref>, do not cont | |||
o not contain | ain | |||
the "uint16 ExtSupportLifetime" field.</t> | the "uint16 ExtSupportLifetime" field.</t> | |||
<t>For brevity and reproducibility all DNS zones involved with the test | <t>For brevity and reproducibility, all DNS zones involved with the test | |||
vectors are signed using keys with algorithm 13: ECDSA Curve P-256 | vectors are signed using keys with algorithm 13 (ECDSA Curve P-256 | |||
with SHA-256.</t> | with SHA-256).</t> | |||
<t>To reflect operational practice, different zones in the examples are | <t>To reflect operational practice, different zones in the examples are | |||
in different phases of rolling their signing keys:</t> | in different phases of rolling their signing keys:</t> | |||
<ul> | <ul> | |||
<li><t>All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK), | <li><t>All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK), | |||
except for the example.com and example.net zones which use a | except for the <tt>example.com</tt> and <tt>example.net</tt> zones, which use a | |||
Combined Signing Key (CSK).</t> | Combined Signing Key (CSK).</t> | |||
</li> | </li> | |||
<li><t>The root and org zones are rolling their ZSK's.</t> | <li><t>The root and org zones are rolling their ZSKs.</t> | |||
</li> | </li> | |||
<li><t>The com and org zones are rolling their KSK's.</t> | <li><t>The com and org zones are rolling their KSKs.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>The test vectors are DNSSEC valid in the same period as the | <t>The test vectors are DNSSEC valid in the same period as the | |||
certificate is valid, which is in between November 28, 2018 and | certificate is valid, which is between November 28, 2018 and | |||
December 2, 2020 and with the following root trust anchor:</t> | December 2, 2020 with the following root trust anchor:</t> | |||
<artwork>. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634 | <sourcecode type="dns-rr">. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613 de3052e37861634 | |||
641bb568746f2ffc4d4 ) | 641bb568746f2ffc4d4 ) | |||
</artwork> | </sourcecode> | |||
<t>The test vectors will authenticate the certificate used with | <t>The test vectors will authenticate the certificate used with | |||
<eref target="https://example.com/">https://example.com/</eref>, <eref target="h ttps://example.net/">https://example.net/</eref> and <eref target="https://examp le.org/">https://example.org/</eref> | <tt>https://example.com/</tt>, <tt>https://example.net/</tt>, and <tt>https://ex ample.org/</tt> | |||
at the time of writing:</t> | at the time of writing:</t> | |||
<artwork>-----BEGIN CERTIFICATE----- | <sourcecode>-----BEGIN CERTIFICATE----- | |||
MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBN | MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBN | |||
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E | MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E | |||
aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMTI4MDAwMDAwWhcN | aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMTI4MDAwMDAwWhcN | |||
MjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju | MjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju | |||
aWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw | aWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw | |||
b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxEzARBgNVBAsT | b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxEzARBgNVBAsT | |||
ClRlY2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZI | ClRlY2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZI | |||
hvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vV | hvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vV | |||
rAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA68o5FGGtFM1yFEaogEv5g | rAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA68o5FGGtFM1yFEaogEv5g | |||
rJ1MRY/d0w4+dw8JwoVlNMci+3QTuUKf9yH28JxEdG3J37Mfj2C3cREGkGNBnY80 | rJ1MRY/d0w4+dw8JwoVlNMci+3QTuUKf9yH28JxEdG3J37Mfj2C3cREGkGNBnY80 | |||
skipping to change at line 810 ¶ | skipping to change at line 866 ¶ | |||
l0QlCzzqzvorGXyB/yd7nttYttzo8EpOAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkC | l0QlCzzqzvorGXyB/yd7nttYttzo8EpOAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkC | |||
wQApBo2yCJo32RMAAAFnXDGWnAAABAMARzBFAiEA5Hn7Q4SOyqHkT+kDsHq7ku7z | wQApBo2yCJo32RMAAAFnXDGWnAAABAMARzBFAiEA5Hn7Q4SOyqHkT+kDsHq7ku7z | |||
RDuM7P4UDX2ft2Mpny0CIE13WtxJAUr0aASFYZ/XjSAMMfrB0/RxClvWVss9LHKM | RDuM7P4UDX2ft2Mpny0CIE13WtxJAUr0aASFYZ/XjSAMMfrB0/RxClvWVss9LHKM | |||
MA0GCSqGSIb3DQEBCwUAA4IBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLeP4R | MA0GCSqGSIb3DQEBCwUAA4IBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLeP4R | |||
8CmgDM1pFAvGBHiyzvCH1QGdxFl6cf7wbp7BoLCRLR/qPVXFMwUMzcE1GLBqaGZM | 8CmgDM1pFAvGBHiyzvCH1QGdxFl6cf7wbp7BoLCRLR/qPVXFMwUMzcE1GLBqaGZM | |||
v1Yh2lvZSLmMNSGRXdx113pGLCInpm/TOhfrvr0TxRImc8BdozWJavsn1N2qdHQu | v1Yh2lvZSLmMNSGRXdx113pGLCInpm/TOhfrvr0TxRImc8BdozWJavsn1N2qdHQu | |||
N+UBO6bQMLCD0KHEdSGFsuX6ZwAworxTg02/1qiDu7zW7RyzHvFYA4IAjpzvkPIa | N+UBO6bQMLCD0KHEdSGFsuX6ZwAworxTg02/1qiDu7zW7RyzHvFYA4IAjpzvkPIa | |||
X6KjBtpdvp/aXabmL95YgBjT8WJ7pqOfrqhpcmOBZa6Cg6O1l4qbIFH/Gj9hQB5I | X6KjBtpdvp/aXabmL95YgBjT8WJ7pqOfrqhpcmOBZa6Cg6O1l4qbIFH/Gj9hQB5I | |||
0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN | 0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN | |||
-----END CERTIFICATE----- | -----END CERTIFICATE----- | |||
</artwork> | </sourcecode> | |||
<section anchor="tv-straight"><name>_443._tcp.www.example.com</name> | <section anchor="tv-straight"><name><tt>_443._tcp.www.example.com</tt></name> | |||
<artwork>_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 | <sourcecode type="dns-rr">_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 | |||
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | |||
922 ) | 922 ) | |||
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 | _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 | |||
20201202000000 20181128000000 1870 example.com. | 20201202000000 20181128000000 1870 example.com. | |||
rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S | rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S | |||
z2BhaswpGLVVuoijuVdzxYjmw== ) | z2BhaswpGLVVuoijuVdzxYjmw== ) | |||
example.com. 3600 IN DNSKEY ( 257 3 13 | example.com. 3600 IN DNSKEY ( 257 3 13 | |||
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s | JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s | |||
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 | /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 | |||
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 | example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 | |||
skipping to change at line 872 ¶ | skipping to change at line 928 ¶ | |||
. 86400 IN DNSKEY ( 256 3 13 | . 86400 IN DNSKEY ( 256 3 13 | |||
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | |||
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | |||
. 86400 IN DNSKEY ( 257 3 13 | . 86400 IN DNSKEY ( 257 3 13 | |||
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | |||
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | |||
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | |||
20181128000000 47005 . | 20181128000000 47005 . | |||
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | |||
nBT1dtNjIczvLG9pQTnOKUsHQ== ) | nBT1dtNjIczvLG9pQTnOKUsHQ== ) | |||
</artwork> | </sourcecode> | |||
<t>A hex dump of the <tt>extension_data</tt> of the server's <tt>dnssec_chain</t t> | <t>A hex dump of the <tt>extension_data</tt> of the server's <tt>dnssec_chain</t t> | |||
extension represention this with an ExtSupportLifetime value of 0 is:</t> | extension representation of this with an ExtSupportLifetime value of 0 is:</t> | |||
<artwork anchor="hex_dump">0000: 00 00 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 | <sourcecode anchor="hex_dump">0000: 00 00 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 | |||
0010: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 | 0010: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 | |||
0020: 01 00 00 0e 10 00 23 03 01 01 8b d1 da 95 27 2f | 0020: 01 00 00 0e 10 00 23 03 01 01 8b d1 da 95 27 2f | |||
0030: 7f a4 ff b2 41 37 fc 0e d0 3a ae 67 e5 c4 d8 b3 | 0030: 7f a4 ff b2 41 37 fc 0e d0 3a ae 67 e5 c4 d8 b3 | |||
0040: c5 07 34 e1 05 0a 79 20 b9 22 04 5f 34 34 33 04 | 0040: c5 07 34 e1 05 0a 79 20 b9 22 04 5f 34 34 33 04 | |||
0050: 5f 74 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 | 0050: 5f 74 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 | |||
0060: 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 | 0060: 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 | |||
0070: 34 0d 05 00 00 0e 10 5f c6 d9 00 5b fd da 80 07 | 0070: 34 0d 05 00 00 0e 10 5f c6 d9 00 5b fd da 80 07 | |||
0080: 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ce 1d | 0080: 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ce 1d | |||
0090: 3a de b7 dc 7c ee 65 6d 61 cf b4 72 c5 97 7c 8c | 0090: 3a de b7 dc 7c ee 65 6d 61 cf b4 72 c5 97 7c 8c | |||
00a0: 9c ae ae 9b 76 51 55 c5 18 fb 10 7b 6a 1f e0 35 | 00a0: 9c ae ae 9b 76 51 55 c5 18 fb 10 7b 6a 1f e0 35 | |||
skipping to change at line 974 ¶ | skipping to change at line 1031 ¶ | |||
0580: 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 ad | 0580: 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 ad | |||
0590: 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 42 | 0590: 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 42 | |||
05a0: 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 bd | 05a0: 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 bd | |||
05b0: 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 63 | 05b0: 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 63 | |||
05c0: ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30 0d | 05c0: ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30 0d | |||
05d0: 00 00 01 51 80 5f c6 d9 00 5b fd da 80 b7 9d 00 | 05d0: 00 00 01 51 80 5f c6 d9 00 5b fd da 80 b7 9d 00 | |||
05e0: de 7a 67 40 ee ec ba 4b da 1e 5c 2d d4 89 9b 2c | 05e0: de 7a 67 40 ee ec ba 4b da 1e 5c 2d d4 89 9b 2c | |||
05f0: 96 58 93 f3 78 6c e7 47 f4 1e 50 d9 de 8c 0a 72 | 05f0: 96 58 93 f3 78 6c e7 47 f4 1e 50 d9 de 8c 0a 72 | |||
0600: df 82 56 0d fb 48 d7 14 de 32 83 ae 99 a4 9c 0f | 0600: df 82 56 0d fb 48 d7 14 de 32 83 ae 99 a4 9c 0f | |||
0610: cb 50 d3 aa ad b1 a3 fc 62 ee 3a 8a 09 88 b6 be | 0610: cb 50 d3 aa ad b1 a3 fc 62 ee 3a 8a 09 88 b6 be | |||
</artwork> | </sourcecode> | |||
</section> | </section> | |||
<section anchor="tv-wildcard-nsec"><name>_25._tcp.example.com NSEC wildcard</nam e> | <section anchor="tv-wildcard-nsec"><name><tt>_25._tcp.example.com</tt> NSEC Wild card</name> | |||
<artwork>_25._tcp.example.com. 3600 IN TLSA ( 3 1 1 | <sourcecode type="dns-rr">_25._tcp.example.com. 3600 IN TLSA ( 3 1 1 | |||
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | |||
922 ) | 922 ) | |||
_25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600 | _25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600 | |||
20201202000000 20181128000000 1870 example.com. | 20201202000000 20181128000000 1870 example.com. | |||
BZawXvte5SyF8hnXviKDWqll5E2v+RMXqaSE+NOcAMlZOrSMUkfyPqvkv53K2 | BZawXvte5SyF8hnXviKDWqll5E2v+RMXqaSE+NOcAMlZOrSMUkfyPqvkv53K2 | |||
rfL4DFP8rO3VMgI0v+ogrox0w== ) | rfL4DFP8rO3VMgI0v+ogrox0w== ) | |||
*._tcp.example.com. 3600 IN NSEC ( smtp.example.com. RRSIG | *._tcp.example.com. 3600 IN NSEC ( smtp.example.com. RRSIG | |||
NSEC TLSA ) | NSEC TLSA ) | |||
*._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 | *._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 | |||
20201202000000 20181128000000 1870 example.com. | 20201202000000 20181128000000 1870 example.com. | |||
skipping to change at line 1043 ¶ | skipping to change at line 1100 ¶ | |||
. 86400 IN DNSKEY ( 256 3 13 | . 86400 IN DNSKEY ( 256 3 13 | |||
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | |||
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | |||
. 86400 IN DNSKEY ( 257 3 13 | . 86400 IN DNSKEY ( 257 3 13 | |||
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | |||
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | |||
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | |||
20181128000000 47005 . | 20181128000000 47005 . | |||
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | |||
nBT1dtNjIczvLG9pQTnOKUsHQ== ) | nBT1dtNjIczvLG9pQTnOKUsHQ== ) | |||
</artwork> | </sourcecode> | |||
</section> | </section> | |||
<section anchor="tv-wildcard-nsec3"><name>_25._tcp.example.org NSEC3 wildcard</n ame> | <section anchor="tv-wildcard-nsec3"><name><tt>_25._tcp.example.org</tt> NSEC3 Wi ldcard</name> | |||
<artwork>_25._tcp.example.org. 3600 IN TLSA ( 3 1 1 | <sourcecode type="dns-rr">_25._tcp.example.org. 3600 IN TLSA ( 3 1 1 | |||
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | |||
922 ) | 922 ) | |||
_25._tcp.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 | _25._tcp.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 | |||
20201202000000 20181128000000 56566 example.org. | 20201202000000 20181128000000 56566 example.org. | |||
lNp6th/CJel5WsYlLsLadcQ/YdSTJAIOttzYKnNkNzeZ0jxtDyEP818Q1R4lL | lNp6th/CJel5WsYlLsLadcQ/YdSTJAIOttzYKnNkNzeZ0jxtDyEP818Q1R4lL | |||
cYzJ7vCvqb9gFCiCJjK2gAamw== ) | cYzJ7vCvqb9gFCiCJjK2gAamw== ) | |||
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 ( | dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 ( | |||
1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA ) | 1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA ) | |||
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG ( | dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG ( | |||
NSEC3 13 3 3600 20201202000000 20181128000000 56566 | NSEC3 13 3 3600 20201202000000 20181128000000 56566 | |||
skipping to change at line 1119 ¶ | skipping to change at line 1176 ¶ | |||
. 86400 IN DNSKEY ( 256 3 13 | . 86400 IN DNSKEY ( 256 3 13 | |||
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | |||
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | |||
. 86400 IN DNSKEY ( 257 3 13 | . 86400 IN DNSKEY ( 257 3 13 | |||
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | |||
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | |||
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | |||
20181128000000 47005 . | 20181128000000 47005 . | |||
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | |||
nBT1dtNjIczvLG9pQTnOKUsHQ== ) | nBT1dtNjIczvLG9pQTnOKUsHQ== ) | |||
</artwork> | </sourcecode> | |||
</section> | </section> | |||
<section anchor="tv-cname"><name>_443._tcp.www.example.org CNAME</name> | <section anchor="tv-cname"><name><tt>_443._tcp.www.example.org</tt> CNAME</name> | |||
<artwork>_443._tcp.www.example.org. 3600 IN CNAME ( | <sourcecode type="dns-rr">_443._tcp.www.example.org. 3600 IN CNAME ( | |||
dane311.example.org. ) | dane311.example.org. ) | |||
_443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600 | _443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600 | |||
20201202000000 20181128000000 56566 example.org. | 20201202000000 20181128000000 56566 example.org. | |||
R0dUe6Rt4G+2ablrQH9Zw8j9NhBLMgNYTI5+H7nO8SNz5Nm8w0NZrXv3Qp7gx | R0dUe6Rt4G+2ablrQH9Zw8j9NhBLMgNYTI5+H7nO8SNz5Nm8w0NZrXv3Qp7gx | |||
Qb/a90O696120NsYaZX2+ebBA== ) | Qb/a90O696120NsYaZX2+ebBA== ) | |||
dane311.example.org. 3600 IN TLSA ( 3 1 1 | dane311.example.org. 3600 IN TLSA ( 3 1 1 | |||
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | |||
922 ) | 922 ) | |||
dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 | dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 | |||
20201202000000 20181128000000 56566 example.org. | 20201202000000 20181128000000 56566 example.org. | |||
skipping to change at line 1194 ¶ | skipping to change at line 1251 ¶ | |||
. 86400 IN DNSKEY ( 256 3 13 | . 86400 IN DNSKEY ( 256 3 13 | |||
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | |||
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | |||
. 86400 IN DNSKEY ( 257 3 13 | . 86400 IN DNSKEY ( 257 3 13 | |||
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | |||
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | |||
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | |||
20181128000000 47005 . | 20181128000000 47005 . | |||
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | |||
nBT1dtNjIczvLG9pQTnOKUsHQ== ) | nBT1dtNjIczvLG9pQTnOKUsHQ== ) | |||
</artwork> | </sourcecode> | |||
</section> | </section> | |||
<section anchor="tv-dname"><name>_443._tcp.www.example.net DNAME</name> | <section anchor="tv-dname"><name><tt>_443._tcp.www.example.net</tt> DNAME</name> | |||
<artwork>example.net. 3600 IN DNAME example.com. | <sourcecode type="dns-rr">example.net. 3600 IN DNAME example.com. | |||
example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20201202000000 | example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20201202000000 | |||
20181128000000 48085 example.net. | 20181128000000 48085 example.net. | |||
o3uV5k5Ewp5fdrOZt0n4QuH+/Hpku2Lo3CzGRt9/MS2zZt2Qb/AXz435UFQBx | o3uV5k5Ewp5fdrOZt0n4QuH+/Hpku2Lo3CzGRt9/MS2zZt2Qb/AXz435UFQBx | |||
OI/pDnjJcLSd/gBLtqR52WLMA== ) | OI/pDnjJcLSd/gBLtqR52WLMA== ) | |||
; _443._tcp.www.example.net. 3600 IN CNAME ( | ; _443._tcp.www.example.net. 3600 IN CNAME ( | |||
; _443._tcp.www.example.com. ) | ; _443._tcp.www.example.com. ) | |||
_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 | _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 | |||
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b | |||
922 ) | 922 ) | |||
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 | _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 | |||
skipping to change at line 1293 ¶ | skipping to change at line 1350 ¶ | |||
sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev | sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev | |||
mDXqz6KEhhQjT+aQWDt6WFHlA== ) | mDXqz6KEhhQjT+aQWDt6WFHlA== ) | |||
com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 | com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 | |||
f9eabb94487e658c188e7bcb52115 ) | f9eabb94487e658c188e7bcb52115 ) | |||
com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e | com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e | |||
70643bbde681db342a9e5cf2bb380 ) | 70643bbde681db342a9e5cf2bb380 ) | |||
com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 | com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 | |||
20181128000000 31918 . | 20181128000000 31918 . | |||
nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb | nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb | |||
vBKTf6pk8JRCqnfzlo2QY+WXA== ) | vBKTf6pk8JRCqnfzlo2QY+WXA== ) | |||
</artwork> | </sourcecode> | |||
</section> | </section> | |||
<section anchor="tv-denial-nsec"><name>_25._tcp.smtp.example.com NSEC Denial of Existence</name> | <section anchor="tv-denial-nsec"><name><tt>_25._tcp.smtp.example.com</tt> NSEC D enial of Existence</name> | |||
<artwork>smtp.example.com. 3600 IN NSEC ( www.example.com. A AAAA | <sourcecode type="dns-rr">smtp.example.com. 3600 IN NSEC ( www.example.com. A AAAA | |||
RRSIG NSEC ) | RRSIG NSEC ) | |||
smtp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 | smtp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 | |||
20201202000000 20181128000000 1870 example.com. | 20201202000000 20181128000000 1870 example.com. | |||
rH/K4wghCOm4jpEHwQKiyZzvFIa7qpFySuKIGGetW4SE4O2Mh5jPxcEzf78Hf | rH/K4wghCOm4jpEHwQKiyZzvFIa7qpFySuKIGGetW4SE4O2Mh5jPxcEzf78Hf | |||
crlsQZmnAUlfmBNCygxAd7JNw== ) | crlsQZmnAUlfmBNCygxAd7JNw== ) | |||
example.com. 3600 IN DNSKEY ( 257 3 13 | example.com. 3600 IN DNSKEY ( 257 3 13 | |||
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s | JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s | |||
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 | /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 | |||
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 | example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 | |||
20201202000000 20181128000000 1870 example.com. | 20201202000000 20181128000000 1870 example.com. | |||
skipping to change at line 1355 ¶ | skipping to change at line 1412 ¶ | |||
. 86400 IN DNSKEY ( 256 3 13 | . 86400 IN DNSKEY ( 256 3 13 | |||
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | |||
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | |||
. 86400 IN DNSKEY ( 257 3 13 | . 86400 IN DNSKEY ( 257 3 13 | |||
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | |||
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | |||
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | |||
20181128000000 47005 . | 20181128000000 47005 . | |||
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | |||
nBT1dtNjIczvLG9pQTnOKUsHQ== ) | nBT1dtNjIczvLG9pQTnOKUsHQ== ) | |||
</artwork> | </sourcecode> | |||
</section> | </section> | |||
<section anchor="tv-denial-nsec3"><name>_25._tcp.smtp.example.org NSEC3 Denial o f Existence</name> | <section anchor="tv-denial-nsec3"><name><tt>_25._tcp.smtp.example.org</tt> NSEC3 Denial of Existence</name> | |||
<artwork>vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN NSEC3 ( | <sourcecode type="dns-rr">vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 I N NSEC3 ( | |||
1 0 1 - 93u63bg57ppj6649al2n31l92iedkjd6 A AAAA RRSIG ) | 1 0 1 - 93u63bg57ppj6649al2n31l92iedkjd6 A AAAA RRSIG ) | |||
vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN RRSIG ( | vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN RRSIG ( | |||
NSEC3 13 3 3600 20201202000000 20181128000000 56566 | NSEC3 13 3 3600 20201202000000 20181128000000 56566 | |||
example.org. | example.org. | |||
wn3cePVdc5VPPniYzGp+1CBPOY2m83/A3cjnAb7FTZuwL45B25fwVUyjKQksh | wn3cePVdc5VPPniYzGp+1CBPOY2m83/A3cjnAb7FTZuwL45B25fwVUyjKQksh | |||
gQeV5KgP1cdvPt1BEowKqK4Sw== ) | gQeV5KgP1cdvPt1BEowKqK4Sw== ) | |||
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 ( | dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 ( | |||
1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA ) | 1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA ) | |||
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG ( | dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG ( | |||
NSEC3 13 3 3600 20201202000000 20181128000000 56566 | NSEC3 13 3 3600 20201202000000 20181128000000 56566 | |||
skipping to change at line 1438 ¶ | skipping to change at line 1495 ¶ | |||
. 86400 IN DNSKEY ( 256 3 13 | . 86400 IN DNSKEY ( 256 3 13 | |||
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | |||
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | |||
. 86400 IN DNSKEY ( 257 3 13 | . 86400 IN DNSKEY ( 257 3 13 | |||
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | |||
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | |||
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | |||
20181128000000 47005 . | 20181128000000 47005 . | |||
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | |||
nBT1dtNjIczvLG9pQTnOKUsHQ== ) | nBT1dtNjIczvLG9pQTnOKUsHQ== ) | |||
</artwork> | </sourcecode> | |||
</section> | </section> | |||
<section anchor="tv-insecure-nsec3-optout"><name>_443._tcp.www.insecure.example NSEC3 opt-out insecure delegation</name> | <section anchor="tv-insecure-nsec3-optout"><name><tt>_443._tcp.www.insecure.exam ple</tt> NSEC3 Opt-Out Insecure Delegation</name> | |||
<artwork>c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN NSEC3 ( | <sourcecode type="dns-rr">c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN NSEC3 ( | |||
1 1 1 - shn05itmoa45mmnv74lc4p0nnfmimtjt NS SOA RRSIG DNSKEY | 1 1 1 - shn05itmoa45mmnv74lc4p0nnfmimtjt NS SOA RRSIG DNSKEY | |||
NSEC3PARAM ) | NSEC3PARAM ) | |||
c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN RRSIG ( | c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN RRSIG ( | |||
NSEC3 13 2 43200 20201202000000 20181128000000 15903 | NSEC3 13 2 43200 20201202000000 20181128000000 15903 | |||
example. | example. | |||
pW16gQOLhLpKYgXpGt4XB4o92W/QoPYyG5CjQ+t+g7LBVcCiPQv8ars1j9UOg | pW16gQOLhLpKYgXpGt4XB4o92W/QoPYyG5CjQ+t+g7LBVcCiPQv8ars1j9UOg | |||
RpXUsJhZBDax2dfDhK7zOk7ow== ) | RpXUsJhZBDax2dfDhK7zOk7ow== ) | |||
shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN NSEC3 ( | shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN NSEC3 ( | |||
1 1 1 - a3ib1dvf1bdtfmd91usrdem5fiiepi6p NS DS RRSIG ) | 1 1 1 - a3ib1dvf1bdtfmd91usrdem5fiiepi6p NS DS RRSIG ) | |||
shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN RRSIG ( | shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN RRSIG ( | |||
skipping to change at line 1484 ¶ | skipping to change at line 1541 ¶ | |||
. 86400 IN DNSKEY ( 256 3 13 | . 86400 IN DNSKEY ( 256 3 13 | |||
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW | |||
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 | |||
. 86400 IN DNSKEY ( 257 3 13 | . 86400 IN DNSKEY ( 257 3 13 | |||
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv | |||
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 | |||
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 | |||
20181128000000 47005 . | 20181128000000 47005 . | |||
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m | |||
nBT1dtNjIczvLG9pQTnOKUsHQ== ) | nBT1dtNjIczvLG9pQTnOKUsHQ== ) | |||
</artwork> | </sourcecode> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="acknowledgments" numbered="false"><name>Acknowledgments</name> | ||||
<t>Many thanks to <contact fullname="Adam Langley"/> for laying the groundwork f | ||||
or this | ||||
extension in <xref target="I-D.agl-dane-serializechain"></xref>. The original id | ||||
ea is his, | ||||
but our acknowledgment in no way implies his endorsement. This | ||||
document also benefited from discussions with and review from the | ||||
following people: <contact fullname="Daniel Kahn Gillmor"/>, <contact fullname | ||||
="Jeff Hodges"/>, <contact fullname="Allison Mankin"/>, | ||||
<contact fullname="Patrick McManus"/>, <contact fullname="Rick van Rein"/>, < | ||||
contact fullname="Ilari Liusvaara"/>, <contact fullname="Eric Rescorla"/>, <co | ||||
ntact fullname="Gowri Visweswaran"/>, <contact fullname="Duane Wessels"/>, <co | ||||
ntact fullname="Nico Williams"/>, and <contact fullname="Richard Barnes"/>.</t> | ||||
</section> | ||||
</back> | </back> | |||
</rfc> | </rfc> | |||
End of changes. 178 change blocks. | ||||
327 lines changed or deleted | 446 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |