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

Nico Williams <nico@cryptonector.com> Mon, 16 April 2018 15:33 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 391DB12778D for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 08:33:11 -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 UOHNgLHyJQUi for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 08:33:09 -0700 (PDT)
Received: from homiemail-a72.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 8B83D126CD8 for <tls@ietf.org>; Mon, 16 Apr 2018 08:33:09 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 61262A00492B; Mon, 16 Apr 2018 08:33:08 -0700 (PDT)
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 4D0FFA004937; Mon, 16 Apr 2018 08:31:35 -0700 (PDT)
Date: Mon, 16 Apr 2018 10:31:11 -0500
From: Nico Williams <nico@cryptonector.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: Eric Rescorla <ekr@rtfm.com>, TLS WG <tls@ietf.org>
Message-ID: <20180416153110.GY25259@localhost>
References: <CAHbuEH78KNyk8fnHThRkCERKPjZzYppi1uhkDx6kL_t448q0_g@mail.gmail.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <CABkgnnUwOjkY1_KejV-YOw3YRqjFfzaYurEY1OpZ8phQVhcWLg@mail.gmail.com> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <aa7ca33a-4acd-c770-a43c-df7a1f66c782@nlnetlabs.nl> <E3918F11-9AD7-4C06-9173-5175ECACD16B@dukhovni.org> <CABcZeBP6-7_NNmC+7iVnNXbQw7p3jJH4eC1-EjY4C4CwdWWNcg@mail.gmail.com> <20180413202936.GX25259@localhost> <CAL02cgTAwwHtFGFh4n1GJ-ApFjKv36o2-uo7+=sXNJ+pztCXsQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL02cgTAwwHtFGFh4n1GJ-ApFjKv36o2-uo7+=sXNJ+pztCXsQ@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yoY0hZ6I9T6FPMMiOjdg2XzZnMU>
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: Mon, 16 Apr 2018 15:33:11 -0000

On Fri, Apr 13, 2018 at 04:38:55PM -0400, Richard Barnes wrote:
> On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams <nico@cryptonector.com>
> wrote:
> > It's better to send the denial of existence than no extension -- the
> > client could just as well be pinning (because the I-D said it could, or
> > because the client does it regardless), and not having extension then
> > will cause failure.
> >
> > Now, clients that don't do opportunistic pinning would have to... notice
> > the lack of TLSA RRs, but not necessarily bother validating the denial
> > of existence chain.  There's not even a need to say that the client
> > SHOULD (let alone MUST) validate the denial of existence chain.  It
> > suffices that the server SHOULD send it.
> 
> Sure seems like it would be simpler to say "Client MUST NOT cache TLSA
> state".  Yes, that cuts off some use cases.  But it avoids all the

That's not the right way to say "no pinning".

> transition pain that EKR has pointed out.

The I-D needs *some* updates.  You and I disagree about which updates,
but it needs updates.  It cannot be published as-is.  Even removing any
kind of pinning requires WG consensus at this point.

And we've already seem that at least one author support (A), and we
could probably easily get support for a (C') where we get the two bytes
we're asking for as well but with as much semantics as possible left for
a follow-on I-D.

Nico
--