Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Viktor Dukhovni <> Thu, 05 April 2018 06:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C853126D73 for <>; Wed, 4 Apr 2018 23:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id geLjU9xo_Gy9 for <>; Wed, 4 Apr 2018 23:46:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49C9E120725 for <>; Wed, 4 Apr 2018 23:46:14 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 80FED7A330D for <>; Thu, 5 Apr 2018 06:46:13 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 05 Apr 2018 02:46:12 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <>
Message-Id: <>
References: <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Apr 2018 06:46:16 -0000

> On Apr 4, 2018, at 1:50 PM, Joseph Salowey <> wrote:
> A) Recommendation of adding denial of existence proofs in the chain provided by the extension
> B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL)
> C) Both

The discussion so far has demonstrated the need for an important clarification about the nature of the pinning in B):

  * The pin would not require *anything* more than continuing support for the extension.
  * In particular, it would not require continued presence of TLSA records, nor even
    continued DNSSEC support by the server's domain.
  * This is because the server can respond with denial of existence of either its TLSA
    records, or even of the the DS records for its domain or some parent domain.

This is why my claim that this is essentially like STS, and nothing like HPKP is valid.

A corollary of the above is that (B) requires (A).  Just (B) alone is not sufficient,
it is too limited a mechanism without denial of existence.

If support for the extension itself is mandatory in some application context (implicit
unbounded pin), then of course (A) alone is enough, but we should note that such implicit
indefinite pinning is fragile during partial deployment and does not protect applications
where the implicit requirement is not an option (incremental deployment).

Therefore, the real choice before us is (C) or not (C), the choices of (A) alone or (B)
alone are unsound half-measures.

(C) is essentially STS for dane chains over TLS with downgrade protection after first
contact, and imposes no burden on the present implementors.  If they were willing to
implement without a pin or denial of existence, they can ignore the pin TTL and never
transmit denial of existence (which their clients would not expect to process).

On the other hand, they may find after some experience that the proposed features
are actually useful, and might add them to their application logic.  I don't know
whether DANE is mandatory with DPRIV or is just an "additive" alternative to WebPKI.
If the latter, with the present draft it is trivially stripped, and again there is
little incentive to not just use WebPKI, especially if DANE support is not required
from all clients (thus servers need at least WebPKI).

Looking at RFC8310, I see hints of support for both WebPKI and DANE, with no guidance
as to how a client is to choose between them, accept either both, avoid downgrades
to one when the other is preferred, ...

So I rather suspect that even the DPRIV use-case, which supposedly does not need
the proposed changes, actually does need them for meaningful security from using
DANE, and we've not just not looked at the details closely enough yet.  It may
well turn out not substantially different from the browser use-case that is not
adequately met by the current draft.

Can someone explain briefly how DPRIV avoids the same downgrade issues, and
negative adoption incentives (cost-benfit comparison)?  If it turns out that
no adequate explanation is possible, and indeed the same issues are present,
then the proposed changes (which are still needed elsewhere) are all the
more pressing.