diff --git a/draft-ietf-tls-dnssec-chain-extension-08.xml b/draft-ietf-tls-dnssec-chain-extension-08.xml index 65264d5..0d403cf 100644 --- a/draft-ietf-tls-dnssec-chain-extension-08.xml +++ b/draft-ietf-tls-dnssec-chain-extension-08.xml @@ -12,7 +12,6 @@ - @@ -85,7 +84,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 +117,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 @@ -150,12 +152,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. @@ -288,7 +293,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 @@ -311,10 +322,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 @@ -376,23 +396,42 @@ - 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.) + 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; 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 + synthetic CNAMES are present, then the TLS client will just ignore + them, as they are not necessary to validate the chain.) + + + + When the response contains valid 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 + records (e.g., NSEC or NSEC3) proving the non-existence of the TLSA RRset or of + insecure delegation, as described in . - 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. + 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 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. @@ -444,6 +483,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 +547,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 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 + facts: @@ -552,14 +650,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, 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 + specification (perhaps application-specific). + + + + 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. @@ -569,15 +672,15 @@ - 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. + 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.
@@ -605,47 +708,14 @@
-
- - - 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 that precluded DANE authentication. 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 @@ -679,10 +749,120 @@ 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. + + +
+
@@ -754,7 +934,6 @@ &rfc3261; &rfc5011; &rfc5905; - &rfc7120; &rfc7250; &rfc7590; &rfc7672;