IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 05 April 2018 15:51 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 3AD9F12D87D for <tls@ietfa.amsl.com>; Thu, 5 Apr 2018 08:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 6AbXNo_VDeHt for <tls@ietfa.amsl.com>; Thu, 5 Apr 2018 08:51:38 -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 8141E12D88D for <tls@ietf.org>; Thu, 5 Apr 2018 08:51:38 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (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 2D3BB7A330D for <tls@ietf.org>; Thu, 5 Apr 2018 15:51:37 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <20180405145454.GP25259@localhost>
Date: Thu, 05 Apr 2018 11:51:17 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <04E74714-BAE2-4142-A03F-DD33B3B30782@dukhovni.org>
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> <20180405145454.GP25259@localhost>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ErK36snHDMXLxgHhOWSNtzgHWKE>
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:51:40 -0000


> On Apr 5, 2018, at 10:54 AM, Nico Williams <nico@cryptonector.com> wrote:
> 
> 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.

When we get past this consensus call, and get to craft the actual text
describing the pin TTL, I would expect a non-zero PIN to only be possible
when proving TLSA records.  A denial of existence should not be able to
set a new pin TTL, and should clear any previous pin TTL.  If DANE is not
actually deployed, there's little reason to pin the extension, and clearing
the pin via denial of existence is a useful mechanism.

A client might then lose access to continued denial of existence until
it again sees actual TLSA records with a non-zero pin, but that seems
OK to me.

-- 
	Viktor.

v2.15.0 | Report a Bug | By Email