IETF Logo Mail Archive

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 04 March 2018 03:44 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 12F70126C2F; Sat, 3 Mar 2018 19:44:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 pVbs7T8Fbl34; Sat, 3 Mar 2018 19:44:18 -0800 (PST)
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 88B8E1200C1; Sat, 3 Mar 2018 19:44:18 -0800 (PST)
Received: from [192.168.0.11] (cpe-98-14-133-144.nyc.res.rr.com [98.14.133.144]) (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 2787F7A3309; Sun, 4 Mar 2018 03:44:17 +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: <CABcZeBP0vzjU5Jf=ZL4WZY56=Lvnn5Ur4gcb3oCb5+M7_CFD-g@mail.gmail.com>
Date: Sat, 03 Mar 2018 22:44:16 -0500
Cc: Shumon Huque <shuque@gmail.com>, draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs <tls-chairs@ietf.org>, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <40C54653-4EAC-4D04-8DDC-304A8E71BA60@dukhovni.org>
References: <CABcZeBOST2X0-MH2hhzpPJaUkbY++udsUV1bMnMhH2V2wQRPmA@mail.gmail.com> <CAHPuVdUs7mUJiqZjFjLDCNmHHGR9AP-g5YaLLbJj-zkDKd=_-w@mail.gmail.com> <alpine.LRH.2.21.1802211425260.7767@bofh.nohats.ca> <CAHPuVdX=_6b5g572-T-9Ccwek-WwL11KdTVwV9oNC9LaO5=0=Q@mail.gmail.com> <alpine.LRH.2.21.1802260913290.9977@bofh.nohats.ca> <70D42B5C-7FF9-49C1-95D4-13FDC611FF96@dukhovni.org> <CAHPuVdU8boBpYO3QutJgawH-54fKD+R9PaaT-5yWE+y2t+BwwA@mail.gmail.com> <CAHPuVdWhEnYxcLUzs-zbnKiN0zj+WO-7_cK2EobS1Gipurk7CQ@mail.gmail.com> <20180227233610.GD8921@localhost> <20180227233854.GE8921@localhost> <20180228200707.GF8921@localhost> <CAHPuVdUOZ1J+us4QfS+AedMvRzTGBRMGHvu5jpOdYr6mENGKXw@mail.gmail.com> <alpine.LRH.2.21.1803032202100.15664@bofh.nohats.ca> <CABcZeBP0vzjU5Jf=ZL4WZY56=Lvnn5Ur4gcb3oCb5+M7_CFD-g@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VFGZCekD018IlfxCH4y7H3jHZzY>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
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: Sun, 04 Mar 2018 03:44:20 -0000

[ Not replying for Paul, I'm sure he he'll post views separately ]

> On Mar 3, 2018, at 10:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Paul, can you walk me through the security value of a proof of nonexistence
> here? Perhaps describe an attack that it stops.

My take is:

Non-existence proofs can clear a pinned DANE policy, where a client would
other require ongoing delivery TLSA records (after initially seeing them
from the server).  The data would not be pinned, that's what the DNSSEC
signed TLSA records are for.

The attack in question is downgrade to just PKIX (with fraudulently
obtained certificates).  Such a downgrade makes PKIX-TA(0) and PKIX-EE(1)
ineffective, and downgrades DANE TlSA to DV certs which are strictly weaker.

Therefore, if the extension were to include an extended pin-TTL, then
denial of existence becomes useful, and indeed the pinning is primarily
a means to make it downgrade-resistant.

-- 
	Viktor.

v2.15.0 | Report a Bug | By Email