Re: [TLS] Draft updates: tls-dnssec-chain

Viktor Dukhovni <> Sat, 28 April 2018 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 241AA127201 for <>; Sat, 28 Apr 2018 11:34:06 -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 zU_pepTEh-ae for <>; Sat, 28 Apr 2018 11:34:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E29C126DFB for <>; Sat, 28 Apr 2018 11:34:04 -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 991687A3309 for <>; Sat, 28 Apr 2018 18:34:03 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Sat, 28 Apr 2018 14:34:02 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [TLS] Draft updates: tls-dnssec-chain
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: Sat, 28 Apr 2018 18:34:06 -0000

> On Apr 28, 2018, at 2:17 PM, Richard Barnes <> wrote:
> Let's just scope this to the additive case.

When you say "additive case" do you mean to cover just applications
where the extension is mandatory?  Or you expect the extension to
also have some value when it is optional?

I thought I explained fairly well why optional use does not pan out,
there was no cost/benefit to refute the one I posted (quoted below).
Servers will never start deploying the non-mandatory 'additive case',
absent downgrade protection, it makes no sense for them to do that:

--- Viktor Dukhovni <>, 2018-04-08 19:27:36-0400 ---
  And yet, as it stands, the deployment cost-benefit analysis for this
  extension in existing applications plays out as follows:


   * You still manage WebPKI certificates to support the majority of existing clients.
   * If the WebPKI is compromised, you're compromised.
   * If DNSSEC is compromised, you're compromised
   * You pay the complexity cost of also supporting the extension
   * You might present incorrect TLSA records and the connection might fail even when
     it would otherwise succeed with WebPKI


   * Nothing other than bragging rights that you're cool enough to
     deploy a shiny new technology

Notably, just a confirmation that the above is basically sound:

--- Martin Thomson <>, 2018-04-05 12:07:57+1000 ---

  Your cost benefit analysis seems about right though.


So with downgrade protection out, the present scope is *exactly* the
applications where the extension is mandatory (whatever these might be).