From 8a99fcc5cec170933d9d271f90d4f5e6556f67eb Mon Sep 17 00:00:00 2001 From: Viktor Dukhovni Date: Wed, 25 Apr 2018 23:55:31 -0400 Subject: [PATCH 1/4] Expand description of denial of existence. Also change MUST use DANE when TLSA records are present to SHOULD use DANE when TLSA records are present AND "usable". With the protocol subject to downgrade attacks, the MUST does not afford any downgrade resistance. The client may do as it pleases and the server is none the wiser. --- draft-ietf-tls-dnssec-chain-extension-08.xml | 152 +++++++++++++++---- 1 file changed, 120 insertions(+), 32 deletions(-) diff --git a/draft-ietf-tls-dnssec-chain-extension-08.xml b/draft-ietf-tls-dnssec-chain-extension-08.xml index 65264d5..cdf747c 100644 --- a/draft-ietf-tls-dnssec-chain-extension-08.xml +++ b/draft-ietf-tls-dnssec-chain-extension-08.xml @@ -150,12 +150,15 @@ The extension described here allows a TLS client to request that the TLS server return the DNSSEC authentication chain corresponding - to its DANE record. If the server is configured for DANE authentication, - then it performs the appropriate DNS queries, builds the authentication - chain, and returns it to the client. The server will usually use a - previously cached authentication chain, but it will need to rebuild it - periodically as described in . The client - then authenticates the chain using a pre-configured trust anchor. + to its DNSSEC-validated DANE TLSA resource record set (RRset), or + authenticated denial of existence of such an RRset (as described in + ). If the server + supports this extension it performs the appropriate DNS queries, + builds the authentication chain, and returns it to the client. The + server will usually use a previously cached authentication chain, but + it will need to rebuild it periodically as described in . The client then authenticates the chain + using a pre-configured trust anchor. @@ -376,23 +379,39 @@ - The first RRset in the chain MUST contain the TLSA record set - being presented. However, if the owner name of the TLSA record - set is an alias (CNAME or DNAME), then it MUST be preceded by the - chain of alias records needed to resolve it. DNAME chains SHOULD - omit unsigned CNAME records that may have been synthesized in the - response from a DNS resolver. (If unsigned synthetic CNAMES are - present, then the TLS client will just ignore them, as they are - not necessary to validate the chain.) + If the owner name of the TLSA RRset is an alias (CNAME or DNAME), + then the chain of signed alias records MUST appear first in the + AuthenticationChain. If at some point along the alias chain the + target of an alias leads to an unsigned zone, the response will be a + denial of existence response proving insecure delegation of that + zone. DNAME chains SHOULD omit unsigned CNAME records that may have + been synthesized in the response from a DNS resolver. (If unsigned + synthetic CNAMES are present, then the TLS client will just ignore + them, as they are not necessary to validate the chain.) - The subsequent RRsets MUST contain the full set - of DNS records needed to authenticate the TLSA record set from the - server's trust anchor. Typically this means a set of DNSKEY - and DS RRsets that cover all zones from the target zone containing - the TLSA record set to the trust anchor zone. The TLS client should - be prepared to receive this set of RRsets in any order. + When the response contains validated TLSA records, the next (barring + aliases, first) RRset in the chain MUST contain the TLSA record set + being presented. + + + + When the response is an authenticated denial of existence, the next + (barring aliases, first) set of RRsets in the chain MUST be the signed + NSEC or NSEC3 records proving the non-existence of the TLSA RRset or + insecure delegation as described in . + + + + The subsequent RRsets MUST contain the full set of DNS records + needed to authenticate the TLSA record set or denial of existence + response via the server's trust anchor. Typically this means a set + of DNSKEY and DS RRsets that cover all zones from the target zone + containing the TLSA record set to the trust anchor zone. The TLS + client should be prepared to receive this set of RRsets in any + order. @@ -444,6 +463,61 @@ + + The following is an example of denial of existence for a TLSA + RRset at "_443._tcp.www.example.com". The NSEC record in this + example asserts the non-existence of both the requested RRset + and any potentially relevant wildcard records. + + +
+ +example.com. IN NSEC (www.example.com. + DNSKEY SOA NS NSEC RRSIG) +RRSIG(example.com. NSEC) +example.com. DNSKEY +RRSIG(example.com. DNSKEY) +example.com. DS +RRSIG(example.com. DS) +com. DNSKEY +RRSIG(com. DNSKEY) +com. DS +RRSIG(com. DS) +. DNSKEY +RRSIG(. DNSKEY) + +
+ + + The following is an example of (hypothetical) insecure delegation of + "example.com" from the ".com" zone. This example shows NSEC3 + records with opt-out. + + +
+ +; covers example.com +onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 - + onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG) +RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3) +; covers *.com +3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 - + 3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG) +RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3) +; closest-encloser "com" +ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 - + ck0pojmg874ljref7efn8430qvit8bsm.com + NS SOA RRSIG DNSKEY NSEC3PARAM) +RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3) +com. DNSKEY +RRSIG(com. DNSKEY) +com. DS +RRSIG(com. DS) +. DNSKEY +RRSIG(. DNSKEY) + +
+
@@ -453,12 +527,16 @@ existence. This specification does not require TLS servers to provide such a denial of existence chain, otherwise it could not be deployed incrementally in environments where not all TLS - servers support this extension. + servers support this extension. Servers MAY instead decline to + use this extension. - Authenticated denial chains include NSEC or NSEC3 records - that demonstrate one of the following facts: + If the extension is not declined, it MUST contain either + authenticated TLSA records or authenticated denial of + existence. Authenticated denial of existence chains include + NSEC or NSEC3 records that demonstrate one of the following + facts: @@ -552,14 +630,19 @@
- A TLS client making use of this specification, and - which receives a DNSSEC authentication chain extension - from a server, MUST use this information to perform - DANE authentication of the server. In - order to do this, it uses the mechanism specified by - the DNSSEC protocol . - This mechanism is sometimes implemented in a DNSSEC - validation engine or library. + A TLS client making use of this specification, and which receives a + DNSSEC authentication chain extension from a server, SHOULD use this + information to perform DANE authentication of the server when the + response is not a denial of existence and has at least one "usable" + TLSA record as defined in or other applicable + specification (perhaps application-specific). + + + + Verification of the authentication chain extension uses the mechanism + specified by the DNSSEC protocol . This mechanism is sometimes implemented in a + DNSSEC validation engine or library. @@ -580,6 +663,11 @@ authentication. + + Clients MAY also cache a denial of existence response up to the + validated negative TTL of such a response. + +
@@ -620,7 +708,7 @@ a proof, a TLS client misdirected to a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to the rogue - server that precluded DANE authentication. Application ecosystems + server that simply omits this extension. Application ecosystems where all TLS servers are expected to implement this extension could require such authenticated denial proofs to be delivered by TLS servers that don't have signed TLSA records. From cde7fd94177ca841cd47959dedacad91bf854436 Mon Sep 17 00:00:00 2001 From: Benjamin Kaduk Date: Fri, 1 Jun 2018 11:13:33 -0500 Subject: [PATCH 2/4] Editorial adjustments to previous commit --- draft-ietf-tls-dnssec-chain-extension-08.xml | 44 ++++++++++---------- 1 file changed, 21 insertions(+), 23 deletions(-) diff --git a/draft-ietf-tls-dnssec-chain-extension-08.xml b/draft-ietf-tls-dnssec-chain-extension-08.xml index cdf747c..9bc0772 100644 --- a/draft-ietf-tls-dnssec-chain-extension-08.xml +++ b/draft-ietf-tls-dnssec-chain-extension-08.xml @@ -379,10 +379,12 @@ - If the owner name of the TLSA RRset is an alias (CNAME or DNAME), + The chain of records appears in logical order for validation. + If the owner name of the TLSA RRset is an alias (e.g., CNAME or DNAME), then the chain of signed alias records MUST appear first in the - AuthenticationChain. If at some point along the alias chain the - target of an alias leads to an unsigned zone, the response will be a + AuthenticationChain; otherwise, the TLSA RRset appears first. + If at some point along the alias chain the + target of an alias leads to an unsigned zone, the response will include a denial of existence response proving insecure delegation of that zone. DNAME chains SHOULD omit unsigned CNAME records that may have been synthesized in the response from a DNS resolver. (If unsigned @@ -391,7 +393,7 @@ - When the response contains validated TLSA records, the next (barring + When the response contains valid TLSA records, the next (barring aliases, first) RRset in the chain MUST contain the TLSA record set being presented. @@ -399,17 +401,18 @@ When the response is an authenticated denial of existence, the next (barring aliases, first) set of RRsets in the chain MUST be the signed - NSEC or NSEC3 records proving the non-existence of the TLSA RRset or - insecure delegation as described in . - The subsequent RRsets MUST contain the full set of DNS records + Following the TLSA or denial of existence RRset, + the subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set or denial of existence response via the server's trust anchor. Typically this means a set of DNSKEY and DS RRsets that cover all zones from the target zone - containing the TLSA record set to the trust anchor zone. The TLS + containing the TLSA or NSEC/NSEC3 record set to the trust anchor zone. The TLS client should be prepared to receive this set of RRsets in any order. @@ -532,7 +535,7 @@ RRSIG(. DNSKEY) - If the extension is not declined, it MUST contain either + If the extension is negotiated, it MUST contain either authenticated TLSA records or authenticated denial of existence. Authenticated denial of existence chains include NSEC or NSEC3 records that demonstrate one of the following @@ -631,7 +634,7 @@ RRSIG(. DNSKEY) A TLS client making use of this specification, and which receives a - DNSSEC authentication chain extension from a server, SHOULD use this + DNSSEC authentication chain extension from a server, uses this information to perform DANE authentication of the server when the response is not a denial of existence and has at least one "usable" TLSA record as defined in or other applicable @@ -639,7 +642,7 @@ RRSIG(. DNSKEY) - Verification of the authentication chain extension uses the mechanism + Verification of the AuthenticationChain contents uses the mechanism specified by the DNSSEC protocol . This mechanism is sometimes implemented in a DNSSEC validation engine or library. @@ -652,20 +655,15 @@ RRSIG(. DNSKEY) - Clients MAY cache the server's validated TLSA RRset or other - validated portions of the chain as an optimization to save - signature verification work for future connections. The + DNS responses have associated TTLs, and clients MAY cache + DNS responses obtained via this extension for the duration of + the validated (negative, for denial of existence records) TTL. + The period of such caching MUST NOT exceed the TTL associated with 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 + TLSA RRset, complete chain, or denial of existence in its cache does not need to send the dnssec_chain extension for subsequent connections to the same TLS - server. It can use the cached information to perform DANE - authentication. - - - - Clients MAY also cache a denial of existence response up to the - validated negative TTL of such a response. + server during the validity period; it can use the cached information instead of what it would have obtained in the server's response to the extension.
@@ -708,7 +706,7 @@ RRSIG(. DNSKEY) a proof, a TLS client misdirected to a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to the rogue - server that simply omits this extension. Application ecosystems + server, which is not obligated to respond to this extension. Application ecosystems where all TLS servers are expected to implement this extension could require such authenticated denial proofs to be delivered by TLS servers that don't have signed TLSA records. From c94c15a85b6638fff5bba7c8656037af869c3a10 Mon Sep 17 00:00:00 2001 From: Benjamin Kaduk Date: Fri, 1 Jun 2018 14:17:13 -0500 Subject: [PATCH 3/4] revamp'd security considerations, extensible reserved field --- draft-ietf-tls-dnssec-chain-extension-08.xml | 175 ++++++++++++++----- 1 file changed, 135 insertions(+), 40 deletions(-) diff --git a/draft-ietf-tls-dnssec-chain-extension-08.xml b/draft-ietf-tls-dnssec-chain-extension-08.xml index 9bc0772..34aee9c 100644 --- a/draft-ietf-tls-dnssec-chain-extension-08.xml +++ b/draft-ietf-tls-dnssec-chain-extension-08.xml @@ -85,7 +85,8 @@ intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS - record lookups. It is not intended to be used to validate + record lookups, in certain situations. + It is not intended to be used to validate the TLS server's address records. @@ -117,7 +118,9 @@ of a TLS server without performing additional DNS record lookups and incurring the - associated latency penalty. It also provides the + associated latency penalty, but inherent difficulties + with having multiple distinct trust hierarchies can limit + its applicability in some situations. It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between @@ -291,7 +294,13 @@ The mechanism for conveying DNSSEC validation chains described in this document results in a commitment by both parties, via the TLS - handshake, to a validated domain name and EE key. + handshake, to a validated domain name and EE key. + Specifically, the relevant DANE records are included + in the TLS handshake transcript hash, so both sides + possess identical records; the client remains responsible + for actually performing the domain name validation of + the DANE records. + The mechanism for encoding DNSSEC authentication chains in a TLS extension, as described in this @@ -314,10 +323,19 @@
+ opaque Reserved<0..255> opaque AuthenticationChain<1..2^16-1>
+ + The Reserved field is reserved for future updates to this + document; in particular it is hoped that the issues discussed + in can be addressed. + Implementations of this specification MUST send a zero-length vector + and ignore the field on receipt. + + The AuthenticationChain structure is composed of a sequence of uncompressed wire format DNS resource record sets (RRset) and @@ -691,47 +709,14 @@ RRSIG(. DNSKEY) -
- - - Green field applications that are designed to always employ this - extension, could of course unconditionally mandate its use. - - - - This protocol allows TLS servers to prove that they don't have a - signed TLSA record by returning a denial of existence chain. - However, as explained in , - it does not require TLS servers to do so. In the absence of such - a proof, a TLS client misdirected to a server that has fraudulently - acquired a public CA issued certificate for the real server's name, - could be induced to establish a PKIX verified connection to the rogue - server, which is not obligated to respond to this extension. Application ecosystems - where all TLS servers are expected to implement this extension could - require such authenticated denial proofs to be delivered by TLS - servers that don't have signed TLSA records. - - - - One possible way to address the threat of attackers that have - fraudulently obtained valid PKIX credentials, is to use current - PKIX defense mechanisms, such as checking Certificate Transparency - logs to detect certificate misissuance. This may be necessary anyway, - as TLS servers may support both DANE and PKIX authentication. Even - TLS servers that support only DANE may be interested in detecting - PKIX adversaries impersonating their service to DANE unaware TLS - clients. - - -
- -
When DANE is being introduced incrementally into an existing PKIX environment, there may be scenarios in which DANE authentication for a server fails but PKIX succeeds, or vice versa. + Some consequences of such scenarios are further discussed in + What happens here depends on TLS client policy. If DANE authentication fails, the client may decide to fallback to traditional PKIX authentication. In order to do so efficiently within the same @@ -765,10 +750,120 @@ RRSIG(. DNSKEY) today. TLS clients MUST support a mechanism to track and rollover the trust anchor key, or be able to avail themselves of a service that does this, as described in . - Security considerations related to mandating the use of this - extension are described in . + +
+ + + Green field applications that are designed to always employ this + extension, could of course unconditionally mandate its use (whether + or not to the exclusion of PKIX authentication). + + + + Other applications seeking to use the functionality provided + by this extension will necessarily undergo some form of + transition period during which both PKIX and DANE are valid + ways to authenticate a TLS server (again, regardless of whether + used alone or in combination). This places the TLS client in + the position of having two (sets of) trust anchors that can be + used to validate TLS server identities -- PKIX and DANE. In + general, this type of situation restricts the security + properties of the system to those of the weakest trust anchor + in the trusted set -- in effect, adding a new trust anchor + makes some usages less secure. Clients that believe the DNS + certification chain for a given site to be weaker than PKIX + gain no benefit from using this extension, so we consider only + the case where DANE is considered equivalent to or + more-trusted than PKIX, and thus the case of an attack on PKIX. + + + + This protocol allows TLS servers to prove that they don't have a + signed TLSA record by returning a denial of existence chain + (and thus, in a transition scenario considered here, that PKIX + should be used for authenticating the server). + However, as explained in , + it does not require TLS servers to do so. In the absence of such + a proof, a TLS client misdirected to a server that has fraudulently + acquired a public CA issued certificate for the real server's name, + could be induced to establish a PKIX verified connection to the rogue + server, which is not obligated to respond to this extension. + Current PKIX defense mechanisms such as Certificate + Transparency can be of use in this case, but are generally not + able to prevent attacks as they happen. + + + + This type of attack is a natural consequence of allowing the + additional trust anchor, as an attacker can choose which + factor to target, whereas the defenders must attempt to secure + all pathways. Ideally, for a given server, a client would + know a priori which mechanism(s) are supported by the (actual) + server, and set its expectations accordingly for what form(s) + of authentication to use. However, absent preconfiguration, + the client initially has no knowledge of the server's support + for DANE (support for PKIX is implicit in the incremental + adoption scenario), and must rely on the communication peer + (and the trust anchors) to provide a reliable indication of + which mechanisms are supported. Returning a DANE chain with + TLSA records clearly indicates support for DANE. DNSSEC + authenticated denial of existence (for TLSA records) provides + an indication, certified by the DNS key hierarchy, that the + server does not support DANE authentication, but under the + assumptions of this specification, there may not be a reliable + way to obtain such DNS records. PKIX, being a separate trust + hierachy, is not authoritative to indicate the lack of a DANE + certification for a given DNS name, so the mere absence of + this extension in a PKIX-authenticated TLS server's response + does not give any data about the presence or absence of a DANE + certification. + + + + A natural tendency is to use past evidence of protocol support + as indication of future support for the protocol (i.e., + "pinning") as a partial remediation. An example of this would be a + "trust-on-first-use" scenario, where a client uses an initial + connection to a server to determine (lack of) support for this + extension, and if the first connection uses this extension, + assume that all future connections to the same server will + also support this extension. Accordingly, a subsequent + connection to that server that does not use this extension + would be an indication of an attack, and grounds for the + client to abort the connection. Unfortunately, this example + is overly simplistic, and does not account for situations + where what presents as a single "server" is actually a "server + farm" with multiple independent backends, which may not have + uniform support for a given feature; it also does not account + for situations where an operator wishes to administratively + disable the use of a feature without breakage. Other + subtleties and complications are possibly not yet known (in + addition to the inherent limitations of pinning as not + applying to the initial connection and requiring repeated + visits during the window of the pin in order to avoid + reintroducing that limitation), and a + comprehensive solution not yet available. Nonetheless, this + document is being published without a remediation strategy in + order to allow for deployments in scenarios where the issues + due to multiple trust anchors do not arise. It is expected + that the Reserved field can be used to support a remediation + strategy in a backwards-compatible fashion. + + + + Due to the myriad of potential complications listed above, + implementations of this specification MUST NOT treat support + for this extension on one connection as indication of support + for this extension on future connections (i.e., must not + "pin"). Pinning may still be permitted given additional + application-specific or preconfigured knowledge about a given + server. + + +
+
From f47795245fd10625da0a0aa9fa70cf97474937ea Mon Sep 17 00:00:00 2001 From: Benjamin Kaduk Date: Fri, 1 Jun 2018 14:19:13 -0500 Subject: [PATCH 4/4] remove unused RFC7120 entity+reference --- draft-ietf-tls-dnssec-chain-extension-08.xml | 2 -- 1 file changed, 2 deletions(-) diff --git a/draft-ietf-tls-dnssec-chain-extension-08.xml b/draft-ietf-tls-dnssec-chain-extension-08.xml index 34aee9c..0d403cf 100644 --- a/draft-ietf-tls-dnssec-chain-extension-08.xml +++ b/draft-ietf-tls-dnssec-chain-extension-08.xml @@ -12,7 +12,6 @@ - @@ -935,7 +934,6 @@ RRSIG(. DNSKEY) &rfc3261; &rfc5011; &rfc5905; - &rfc7120; &rfc7250; &rfc7590; &rfc7672;