[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.