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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 12 April 2018 22:09 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 AA7A312D7F9 for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 15:09:35 -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 wSSUvGEGMZyW for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 15:09:34 -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 2A4E812895E for <tls@ietf.org>; Thu, 12 Apr 2018 15:09:34 -0700 (PDT)
Received: from [10.200.0.109] (unknown [8.2.105.17]) (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 B97A27A3309 for <tls@ietf.org>; Thu, 12 Apr 2018 22:09:32 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABkgnnUwOjkY1_KejV-YOw3YRqjFfzaYurEY1OpZ8phQVhcWLg@mail.gmail.com>
Date: Thu, 12 Apr 2018 18:09:31 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <CAHPuVdXfVQ5ZYL+dTvFeTfOaz2NNPrqxvnWuqJkxu0aaKDF_Sg@mail.gmail.com> <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <alpine.LRH.2.21.1804120438460.24369@bofh.nohats.ca> <CAL02cgSuTOaT_NwnpXaa8DPhNJhzqZwepRL+J29BzcBfCTDtHw@mail.gmail.com> <CAHbuEH78KNyk8fnHThRkCERKPjZzYppi1uhkDx6kL_t448q0_g@mail.gmail.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <CABkgnnUwOjkY1_KejV-YOw3YRqjFfzaYurEY1OpZ8phQVhcWLg@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OsiyDBpKljxN8LNuax66-wQ5MS0>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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: Thu, 12 Apr 2018 22:09:35 -0000


> On Apr 12, 2018, at 5:47 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D
> that enacts the changes they wish to see?

Why publish a crippled specification that needs immediate amendments that would
require a second parallel extension to be defined and used by clients and servers
to fix the issues in the current specification?  And the time to get that second
extension would effectively delay the publication of a usable protocol.

The protocol as described prohibits denial of existence responses.  Willem
acknowledged (thus far in an off-list message) that that's an oversight that
should be corrected, and such a correction is the substance of option (A).

The protocol as described does not provide any mechanism for client to
distinguish between servers that are ready to commit to the extension
and those are not.  This negates applicability in applications that
exist in a world dominated by the WebPKI.  Note that I also don't
advocate any magical vision of the WebPKI going away any time soon.
Indeed some of these applications (e.g. browsers) might choose
to support only *at least* WebPKI, with DANE for optional hardening
(PKIX-TA(0), PKIX-EE(1)), but the present draft provides no downgrade
protection for this use-case.

The additional commitment signal is a hint to clients, not an obligation,
it carries negligible cost, and can be finalized now.  It enables more
potential applications, without going back to square-zero and doing another
year in the IETF WG process to address the gap.

Let's do the right thing and fix now.  The entire cost is just a small
delay, there is zero downside after that.  No imposed complexity.  Just
an improved scope.  We all want to get stuff published and out the door,
but let's take a *little* extra time to make sure it is not needlessly
crippled.

-- 
	Viktor.