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

Nico Williams <nico@cryptonector.com> Thu, 05 April 2018 15:15 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 0B28A129C70 for <tls@ietfa.amsl.com>; Thu, 5 Apr 2018 08:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] 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 I8nWQmp8tSU6 for <tls@ietfa.amsl.com>; Thu, 5 Apr 2018 08:15:38 -0700 (PDT)
Received: from homiemail-a111.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 8EC6312DA06 for <tls@ietf.org>; Thu, 5 Apr 2018 08:15:38 -0700 (PDT)
Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 647C93C012B31; Thu, 5 Apr 2018 08:15:37 -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=6iqXby5oQi8EFT wR9ZRYvLqD2bc=; b=KDzvyjIxFRbYXJmRKBBwIA8U/d4SBfh562OYp/bgYhiVKW IlD/fEEZvMdwN5eJs/co3Ev6MHvlfUURpx1RojhN5m/CFvln4Q981cYoANovoNcy 4jZmKwXiQMf8pPtzV92H7z4MwSf8S4sTPk7Sv52jn0WpX8uJC2A4tUuRrCCL8=
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-a111.g.dreamhost.com (Postfix) with ESMTPSA id 103673C012B27; Thu, 5 Apr 2018 08:15:36 -0700 (PDT)
Date: Thu, 05 Apr 2018 09:54:55 -0500
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: TLS WG <tls@ietf.org>
Message-ID: <20180405145454.GP25259@localhost>
References: <EDB0F480-1272-4364-9A3D-23F9E1A02141@dukhovni.org> <CABkgnnWBdp=KtmBVDcrR9-5tdVPfhWG7pWR0FE57H=iWS37dWw@mail.gmail.com> <C52564E1-ABCD-4E1A-8517-19743BD2180B@dukhovni.org> <CABcZeBMcvtQ6Ko-2Rmoq3BSVBOqdQwJ65vVrPK0cpSJ9nQCS3w@mail.gmail.com> <20180405022007.GG25259@localhost> <CABcZeBMGdXPF9if8Z_Gnc5MoOrZAOPEV2K3i5Bd_ewC6fdxOEg@mail.gmail.com> <20180405023456.GK25259@localhost> <CABcZeBM8MPMhpb9LpqkWAV7LmsUabk3Q7CtxLFaFMFLQVg-H0g@mail.gmail.com> <20180405030945.GN25259@localhost> <CABcZeBNJE+iCccpCt0-BgP79q7eaR6atVQDKF9GmwadiSV=5iA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBNJE+iCccpCt0-BgP79q7eaR6atVQDKF9GmwadiSV=5iA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZdeXird2hfb_NaqCvCAspdkkNRs>
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, 05 Apr 2018 15:15:40 -0000

On Wed, Apr 04, 2018 at 08:39:37PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams <nico@cryptonector.com> wrote:
> > Either way it's the same impact: you cannot roll that key over.
> >
> > Whereas with pin-to-DANE there's no such problem.  I thought I made that
> > clear.
> 
> Yes, I agree that you're relying on a different guarantee from your
> parent zone, I just don't think it's particularly obvious that that
> guarantee is easier to ensure, for the reasons I indicated previously.

Sure it is.  As long as the root zone is signed you can use this
extension and prove that you are / are not using DANE.

> > > And, of course, if you're concerned with hijacking attacks, the
> > > > > hijacker will just advertise a very long TTL.
> > > >
> > > > But it's a TOFU-ish thing.  The server impersonator has to have the
> > > > right timing or else be detected -- that's very risky for them, and a
> > > > deterrent to even trying.  It's not fool-proof, but it's not nothing
> > > > either.
> > >
> > > Given that the motivation for this kind of hijacking was generally
> > > expected to be vandalism or ransom, this doesn't seem very comforting.
> >
> > The motivation for opportunistically using this is to be able to
> > incrementally deploy DANE for HTTPS (and browsers).  Without that it
> > won't get deployed at all for HTTPS.
> 
> I don't see how this is responsive to the concern that this technique will
> be used for hijacking.

You're right.  I believe this has been answered now separately by
others, and also by me.

This is not a pin-to-DANE feature we're asking for, but a
pin-to-using-this-extension.  I shouldn't have called it pin-to-DANE,
but I did because it's short -- short, but not sufficiently pithy :(

Now, it's true that an impersonator could force you to use this
extension when you were not ready to, and that's a DoS, though an easy
one to fix, relatively.  I'll take that DoS over a downgrade attack.

We could mitigate the DoS by saying that the pin TTL must be coerced to
zero (or maybe 1) if the extension only bore an authenticated denial of
existence.  I would prefer to not have to do this, but I'd accept it.

Nico
--