[TLS] A new argument (Re: Consensus Call on draft-ietf-tls-dnssec-chain-extension)

Nico Williams <nico@cryptonector.com> Wed, 11 April 2018 03:49 UTC

Return-Path: <nico@cryptonector.com>
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 CB29B126DFF for <tls@ietfa.amsl.com>; Tue, 10 Apr 2018 20:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 Eh7lUZCni-IC for <tls@ietfa.amsl.com>; Tue, 10 Apr 2018 20:49:01 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42D41201F8 for <tls@ietf.org>; Tue, 10 Apr 2018 20:49:01 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 8549F30005C29; Tue, 10 Apr 2018 20:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=66g4h01aa/6CU5 xj9K1wKl7ln8E=; b=d9uGSu6qz69cbcjU1WduZC84gi0PCynhKrUX4T8IN2kQKJ kk7bXCHNcSi+MeOyP1OVh/jT2j2TPMNe1Wb8weU4fksLznbrBVlFlciCddsxpAnA 5JQQjWJtiEYwRQKtEk6IaigwDV1xARnPFHWd2Hy4PeEfWttUGIOjmkcxhfF8g=
Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 2276230005C25; Tue, 10 Apr 2018 20:49:01 -0700 (PDT)
Date: Tue, 10 Apr 2018 22:42:04 -0500
From: Nico Williams <nico@cryptonector.com>
To: Joseph Salowey <joe@salowey.net>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20180411034203.GU25259@localhost>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kVVcVwXyBPR6SHSrvDpUD0ewDzQ>
Subject: [TLS] A new argument (Re: 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: Wed, 11 Apr 2018 03:49:04 -0000

Let me synthesize one new argument, though I've implied it before, but I
think making it explicit may be useful:

  The cost of making the requested changes is fixed and can be estimated
  -- measured even, after the fact.  I argue that cost is low.  But the
  cost/risk of not making the requested changes is intangible -- could
  be very high, or barely more (but not less) than the cost of making
  the changes.

  We'd have to be sanguine to dismiss my estimate of the cost/risk of
  fixing this later.  Perhaps that's right anyways, but it can plausibly
  be very large too, and that surely should trump a small fixed cost,
  therefore we're better off taking this hit now.

I might clarify other points on the main thread, but, really, for me,
the whole thing boils down to: are we looking out for the future, and is
our contention of risk to future DANE deployment even plausible.

It won't surprise anyone that I believe my estimate of the risk to
future DANE deployment is not merely plausible.

It won't surprise anyone either that I believe that even if the
likelihood of reduction of future DANE deployment were low, we, the
IETF, and in particular the IESG, ought to care about making our
protocols sufficiently generic when the cost of doing so is low, as
surely it would be here.

We've already incurred what should be much of the cost of making the
requested changes.  A wee bit little more won't hurt.  Let us now then
proceed to proposed text.

Nico
--