[TLS] Proposed text for dnsssec chain extension draft
Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 25 April 2018 05:34 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F8E126FB3 for <tls@ietfa.amsl.com>; Tue, 24 Apr 2018 22:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uEuhPuVqGQs for <tls@ietfa.amsl.com>; Tue, 24 Apr 2018 22:34:16 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6712126B7E for <tls@ietf.org>; Tue, 24 Apr 2018 22:34:16 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id CF5477A3309 for <tls@ietf.org>; Wed, 25 Apr 2018 05:34:14 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Message-Id: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org>
Date: Wed, 25 Apr 2018 01:33:54 -0400
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/oHQlv7YeMwoGSGuEwjXTQzXg_XM>
Subject: [TLS] Proposed text for dnsssec chain extension draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2018 05:34:19 -0000
I've been asked to write up proposed changes to the DNSSEC chain extension draft (with the 16-bit extension support lifetime field). In doing that I've discovered that adding the 16-bit field is a minor tweak to the document text, but, ironically, describing denial of existence, though a simple idea, requires extensive surgery to the document. Below I do both, in the hope that either or both will prove useful. Perhaps a concrete proposal will make it easier to reach a mutually-agreeable consensus position, and make it clear that the requested 16-bits are a reasonable consensus outcome. I'm also willing to create a pull request against: https://github.com/MelindaShore/dnssec-serialization if there's interest in me doing that. Below I list OLD/NEW text chunks with the name of the section in which they fit. --- Change 1: Section 2. Introduction. * Add denial of existence OLD: 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 Section 5. The client then authenticates the chain using a pre-configured trust anchor. NEW: The extension described here allows a TLS client to request that the TLS server return the DNSSEC authentication chain corresponding to its DANE TLSA resource record set (RRset), or authenticated denial of existence of that RRset. 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 Section 5. The client then authenticates the chain using a pre-configured trust anchor. When the requested TLSA RRset does not exist, and/or the containing DNS zone is not DNSSEC-signed, the server MAY return a chain of records that establish authenticated denial of existence of the TLSA RRset, or prove insecure delegation (an ancestor) of that domain. Alternatively, the server MAY simply not negotiate the extension. --- Change 2: Section 3.4. DNSSEC Authentication Chain Data * Add 16-bit SupportLifetime field OLD: The "extension_data" field of the "dnssec_chain" extension MUST contain a DNSSEC Authentication Chain encoded in the following form: opaque AuthenticationChain<1..2^16-1> NEW: The "extension_data" field of the "dnssec_chain" extension MUST contain a DNSSEC Authentication Chain encoded in the following form: struct { uint16 SupportLifetime; opaque AuthenticationChain<1..2^16-1>; } DnssecChainExtension; A zero "SupportLifetime" prohibits the client from unilaterally requiring ongoing use of the extension based on prior observation of its use (pinning). A future specification will define the semantics of non-zero values of the SupportLifetime field. Servers implementing only the present specification MUST set the SupportLifetime element to zero. Clients implementing only the present specification MUST treat any value received as though it were zero. --- Change 3: Section 3.4. DNSSEC Authentication Chain Data * Add denial of existence OLD: The first RRset in the chain MUST contain the TLSA record set being presented. [...] The subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set from the server's trust anchor. [...] NEW: When the response contains validated TLSA records, the first RRset in the chain MUST contain the TLSA record set being presented. [...] When the response is an authenticated denial of existence, after any initial DNSSEC-signed CNAME and/or DNAME records redirecting the requested TLSA RRset, the next RRset in the chain MUST be the signed SOA record of the domain that is proving the non-existence of the TLSA RRset or its insecure delegation. The SOA record MUST be followed by the relevant signed NSEC or NSEC3 records. 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. [...] --- Change 4: Section 3.4. DNSSEC Authentication Chain Data * Add denial of existence examples: OLD: The following is an example of the records in the AuthenticationChain [...] RRSIG(. DNSKEY) NEW: The following is an example of the records in the AuthenticationChain [...] RRSIG(. DNSKEY) The following is a TLSA RRset denial-of-existence example: example.com. IN SOA RRSIG(example.com. SOA) example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC 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 insecure delegation example (with NSEC3 opt-out): com. IN SOA RRSIG(com. SOA) GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3 (1 1 0 - - GPIOVE5CC3CA0D1H14G1GI4J0835GEKB NS DS RRSIG) RRSIG(GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3) com. DNSKEY RRSIG(com. DNSKEY) com. DS RRSIG(com. DS) . DNSKEY RRSIG(. DNSKEY) --- Change 5: Section 6. Verification * Add denial of existence * Note that TLSA records might not be "usable" (new issue in the document, sorry, but clients should not have to honour unusable TLSA records) OLD: 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 [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a DNSSEC validation engine or library. NEW: A TLS client making use of this specification, which receives a verifiable DNSSEC authentication chain extension from a server, MUST 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 [RFC6698], [RFC7671] and any other applicable specifications (perhaps application-specific). Verification of the authentication chain extension uses the mechanism specified by the DNSSEC protocol [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a DNSSEC validation engine or library. [... New final paragraph for Section 6 ...] Clients MAY also cache a denial of existence response up to the validated negative TTL of such a response. --- Change 6: Section 8. Mandating use of this extension * Prohibit unilateral pinning, clarify downgrade. OLD: If TLS applications want to mandate the use of this extension for specific servers, clients could maintain a whitelist of sites where the use of this extension is forced. The client would refuse to authenticate such servers if they failed to deliver this extension. Client applications could also employ a Trust on First Use (TOFU) like strategy, whereby they would record the fact that a server offered the extension and use that knowledge to require it for subsequent connections. This protocol currently provides no way for a server to prove that it doesn't have a TLSA record. Hence absent whitelists, a 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. This could be solved by enhancing this protocol to require that servers without TLSA records need to provide a DNSSEC authentication chain that proves this (i.e. the chain includes NSEC or NSEC3 records that demonstrate either the absence of the TLSA record, or the absence of a secure delegation to the associated zone). Such an enhancement would be impossible to deploy incrementally though since it requires all TLS servers to support this protocol. NEW: Pending a future specification that defines the semantics of non-zero values of the SupportLifetime element of the extension, clients MUST NOT employ "pinning" to require use of the extension by servers previously observed to support it. Servers that implement only this specification MUST set the SupportLifetime element to zero. In the absence of "pinning", when the extension is not mandatory, a client cannot reliably determine which servers don't have TLSA records. Hence, a client communicating with 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 a rogue server that simply omits this extension. --- Editorial Appendix A. Test vectors s/reproducability/reproducibility/ This section should probably include new denial of existence test vectors. -- Viktor.
- [TLS] Proposed text for dnsssec chain extension d… Viktor Dukhovni
- Re: [TLS] Proposed text for dnsssec chain extensi… Melinda Shore
- Re: [TLS] Proposed text for dnsssec chain extensi… Willem Toorop
- Re: [TLS] Proposed text for dnsssec chain extensi… Willem Toorop
- Re: [TLS] Proposed text for dnsssec chain extensi… Nico Williams
- Re: [TLS] Proposed text for dnsssec chain extensi… Viktor Dukhovni
- Re: [TLS] Proposed text for dnsssec chain extensi… Joseph Salowey
- Re: [TLS] Proposed text for dnsssec chain extensi… Nico Williams
- Re: [TLS] Proposed text for dnsssec chain extensi… Nico Williams
- Re: [TLS] Proposed text for dnsssec chain extensi… Joseph Salowey
- Re: [TLS] Proposed text for dnsssec chain extensi… Viktor Dukhovni
- Re: [TLS] Proposed text for dnsssec chain extensi… Nico Williams
- Re: [TLS] Proposed text for dnsssec chain extensi… Viktor Dukhovni
- Re: [TLS] Proposed text for dnsssec chain extensi… Eric Rescorla
- Re: [TLS] Proposed text for dnsssec chain extensi… Viktor Dukhovni
- Re: [TLS] Proposed text for dnsssec chain extensi… Eric Rescorla
- Re: [TLS] Proposed text for dnsssec chain extensi… Viktor Dukhovni
- Re: [TLS] Proposed text for dnsssec chain extensi… Eric Rescorla
- Re: [TLS] Proposed text for dnsssec chain extensi… Nico Williams
- Re: [TLS] Proposed text for dnsssec chain extensi… Richard Barnes
- Re: [TLS] Proposed text for dnsssec chain extensi… Nico Williams
- Re: [TLS] Proposed text for dnsssec chain extensi… Paul Wouters
- Re: [TLS] Proposed text for dnsssec chain extensi… Richard Barnes
- Re: [TLS] Proposed text for dnsssec chain extensi… Eric Rescorla
- Re: [TLS] Proposed text for dnsssec chain extensi… Viktor Dukhovni
- Re: [TLS] Proposed text for dnsssec chain extensi… Nico Williams
- Re: [TLS] Proposed text for dnsssec chain extensi… Nico Williams
- Re: [TLS] Proposed text for dnsssec chain extensi… Nico Williams
- Re: [TLS] Proposed text for dnsssec chain extensi… Viktor Dukhovni