[TLS] Draft updates: tls-dnssec-chain

Shumon Huque <shuque@gmail.com> Sat, 28 April 2018 16:19 UTC

Return-Path: <shuque@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 65B7D126C25 for <tls@ietfa.amsl.com>; Sat, 28 Apr 2018 09:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jNxOhzMWq5O2 for <tls@ietfa.amsl.com>; Sat, 28 Apr 2018 09:19:51 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A86124234 for <tls@ietf.org>; Sat, 28 Apr 2018 09:19:51 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id x144-v6so5120567itc.0 for <tls@ietf.org>; Sat, 28 Apr 2018 09:19:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1nk9i0trKtsLjAmp++7/mSYyZNgfnZdpT6aOMRHRuJk=; b=DS44+MuimpZF4ULHcHaQlRuOn5p7Xp/4b2+s5qv9R1GUUs8GnSsr4hcGew8uiIt4OW K03O3pOvR71GR1vRW75dym+VxGHXzNOp4KKKey/dVt04f329WZqXkoLFVcrztwfg+tJ6 gUEA50dMAwL27XB4ZMYMULO9Ix26WpRuP+Zs+9JUNaPRnq5Ix6p3+oWt2vOzDZX35HBh fyw1JURXEfeQ5tKIsufxxMQNSnH1CMBceKMHvYLWcz/kvp+/opHTZLv2XRECk9omibb2 DW+MVWOxNOceiUxSt2pyVl/5h/T0JdMbMMFAeIq7Tbpe602103yTEk9KyZZEJjWsTubV mFwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1nk9i0trKtsLjAmp++7/mSYyZNgfnZdpT6aOMRHRuJk=; b=LGgyecNPwvtZYqcYh8akA31Kq1tvael8yx0TOdGcIkYTWXBYSoHjYTd8IVTbNBAXpH 1FzJloZFND1txA1fed8d+6NUbg3YuE7ALbLuCuKhzKOX1FSoiNdtOoROFp2BxHvAJx8R N4aBzt7kVo21d9ISiwNvWPpkNOSXyJ9aoG8KG2e10A+NDYm1qh1rBN+/Q/bLuygwHCQx C1RzhgQNhU8NUkfAVWmSRNSMA/4g4H3Qi/ajuhVdZa5gfYZWMABvPyyzz5tpSvx9Aa62 ylnLxsYu2+Pc7EYw8yr6Bq/zdlTBAEMHSpNKiOoVcAjQghs1sIacLHt4uhfokTmF8T1b X7/w==
X-Gm-Message-State: ALQs6tAQMZ4xrVjWTGjyS0qDJQ2bGc0/xWwWZ+bjXnIdCAQ5ZtSlinNR 1zdRkWBhwNUpmQcn1akBdlpLsxkTIUASp9DQWARerXJU
X-Google-Smtp-Source: AB8JxZr1l+RL/5vqAt/3AMRrMkaiBByzgFF6JA9T+2ViP6h8SZeAOmcIWQHTBd/EVlHNeB2/hECU6wB+s2gFSLiH/mA=
X-Received: by 2002:a24:5fca:: with SMTP id r193-v6mr5653652itb.89.1524932390453; Sat, 28 Apr 2018 09:19:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 09:19:49 -0700 (PDT)
From: Shumon Huque <shuque@gmail.com>
Date: Sat, 28 Apr 2018 12:19:49 -0400
Message-ID: <CAHPuVdW4kJQ5-mhCGR9BW6dDaN25Lv_Dsr9ygoNwrDsC=c7vuA@mail.gmail.com>
To: TLS WG <tls@ietf.org>, Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="0000000000007089e1056aeafd4d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/y9hBG7Mb3hmrdB89wMoPwaLjbfs>
Subject: [TLS] Draft updates: tls-dnssec-chain
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: Sat, 28 Apr 2018 16:19:53 -0000

> On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey <joe@salowey.net> wrote:

> Concerns have been raised about the trade-offs associated with pinning
and I do not think we currently have consensus to add pinning.  While I
think it may be possible to come to consensus on pinning I think it may
take some time.  I believe we can quickly get consensus for the following
> 1. Scope the document to the assertive use cases
> 2. Explicitly allow (but do not require) DoE be included
> 3. Remove current text about pinning
> 4. Re-submit the document for publication and start work on a separate
extension that supports pinning

Hi Joe,

Here is the proposed text for items 1, 2, and 3. It's also in the
tls-wg github repo. We'll probably tweak and wordsmith some more,
but this is the gist of it.

> 1. Scope the document to the assertive use cases

* Added scope description to Intro:

   This specification can also be used to optionally convey
   authenticated denial of existence of TLSA records.  Restrictive uses
   that might require such proofs (such as the PKIX constraining modes
   of DANE, or where DANE should always be preferred over other modes of
   authentication such as traditional PKIX) are thus not in its intended
   scope.  Such restrictive uses can however be supported

> 2. Explicitly allow (but do not require) DoE be included

(Note: I've noticed Viktor has submitted some expanded text
describing denial of existence. We'll review and likely incorporate
much of that)

* New section: 3.4.1, that permits but doesn't require authenticated denial:

3.4.1.  Support for Authenticated Denial of Existence

   TLS servers that do not have a signed TLSA record MAY instead return
   a DNSSEC chain that provides authenticated denial of 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.

   Authenticated denial chains include NSEC or NSEC3 records that
   demonstrate one of the following facts:

   o  The TLSA record does not exist.

   o  There is no signed delegation to a DNS zone which is either an
      ancestor of, or the same as, the TLSA record name.

* Text in Section 8 (Mandating) that rewrites language that in the
  previous draft stated that it doesn't support denial of existence:

   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 Section 3.4.1, 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.

> 3. Remove current text about pinning

* Remove client initiated pinning para from Section 8:

  This paragraph was entirely deleted:

   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.

Shumon Huque