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

Nico Williams <nico@cryptonector.com> Wed, 11 April 2018 00:37 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 D25DA12D944 for <tls@ietfa.amsl.com>; Tue, 10 Apr 2018 17:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 fDqJTncNW0Xq for <tls@ietfa.amsl.com>; Tue, 10 Apr 2018 17:37:40 -0700 (PDT)
Received: from homiemail-a33.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 8F5B6120713 for <tls@ietf.org>; Tue, 10 Apr 2018 17:37:40 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 892BBA004F2D; Tue, 10 Apr 2018 17:37:32 -0700 (PDT)
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-a33.g.dreamhost.com (Postfix) with ESMTPSA id 980C1A004F1C; Tue, 10 Apr 2018 17:37:19 -0700 (PDT)
Date: Tue, 10 Apr 2018 19:26:34 -0500
From: Nico Williams <nico@cryptonector.com>
To: Melinda Shore <melinda.shore@nomountain.net>
Cc: tls@ietf.org
Message-ID: <20180411002633.GT25259@localhost>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <CAHPuVdXfVQ5ZYL+dTvFeTfOaz2NNPrqxvnWuqJkxu0aaKDF_Sg@mail.gmail.com> <20180410235321.GR25259@localhost> <d65fbec0-bad7-1261-9dc7-16606f9f95ca@nomountain.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <d65fbec0-bad7-1261-9dc7-16606f9f95ca@nomountain.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NphsjTlsMuAaRUrMNakvsovyU7s>
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: Wed, 11 Apr 2018 00:37:42 -0000

On Tue, Apr 10, 2018 at 04:17:14PM -0800, Melinda Shore wrote:
> On 4/10/18 3:53 PM, Nico Williams wrote:
> > The earlier consensus is not just applicable, as if it were, we would
> > not be having this LC.
> 
> I have no idea what that even means, to be honest.  We're through
> last call, and it's not that the earlier wg consensus isn't
> "applicable," it's that you've raised new issues.  So let's be
> clear about that.

It means that because we are having this LC, we cannot use the previous
consensus as evidence for ending this LC with a "no".  We might as well
never have had the LC in that case, and it is not a substantive response
to the LC anyways.  It's a "please go away" response.

> I've been watching this discussion and trying to get a handle
> on what's been going on (and how this fits into several other
> IETF issues more generally), and I think this discussion would
> be over if the people arguing in favor of changing the use
> of the extension had plans to implement it.  But so far nobody [...]

Viktor began implementing DANE 8 months after it was published.  That
spec was ready.  This spec is not.

> It's unfortunate that over in DNS-land they're discussing how
> to get rid of unused features that increase complexity, while over
> here we're having a discussion of how to add unused features that
> increase complexity.

Sure, this is true, but it doesn't mean that we should exclude features
that are necessary to making the protocol work in the first place.

This is a TLS extension for stapled DANE, not a DPRIV extension to TLS.

> I think those of us who care about the institutional effectiveness
> of the IETF and the value of the standardization process care
> quite a bit about the amount of time it takes to push a document
> through to publication.  Aside from negatively affecting the chances
> [...]

What is it to "care about the institutional effectiveness of the IETF
..."?  Is it to care only about speediness?  Or only about correctness?
How about a bit of both?

Honestly, if all you want is speediness, why not go to OASIS?  Register
the extension codepoint with IANA and publish elsewhere, why not?

Doing things in the IETF means... the peanut gallery are not just
spectators.  Bringing work to the IETF means incurring the risk that
others may glom onto it.  It happens *all the time*, it's happened to
me, and it will happen to others.  There is nothing special to this
piece of work that should exempt it.

Nico
--