Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
Paul Wouters <paul@nohats.ca> Wed, 15 November 2017 04:11 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452FA1270FC for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 20:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 qEpx9AdERyBZ for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 20:11:08 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0134C124217 for <dnsop@ietf.org>; Tue, 14 Nov 2017 20:11:08 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yc9sk1dFGz30y; Wed, 15 Nov 2017 05:11:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510719066; bh=xVPdmKCR5Sc1QEDTraBzRjbebj+i6vRl/D9XTwGUV24=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=B8lKTp3V4vIUciKA91Cb019Z20azAzpel9ekUrFr31igF70L07m7oAjUbE1rVd/sM DpwtTKnjTDJOgtYRywE0R1Y5aiOaJyJVmZg0f2pIrIxQcklnUH2MyL4a+aANFd2bWy xTqooiDethnbx3UgIUeHdq/GTL9/jLwDS9YqxxI8=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 7juUjOrMaZ1v; Wed, 15 Nov 2017 05:11:05 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 15 Nov 2017 05:11:05 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2537862D29; Tue, 14 Nov 2017 23:11:04 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2537862D29
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0E6A940D35AF; Tue, 14 Nov 2017 23:11:04 -0500 (EST)
Date: Tue, 14 Nov 2017 23:11:03 -0500
From: Paul Wouters <paul@nohats.ca>
To: Frederico A C Neves <fneves@registro.br>
cc: "dnsop@ietf.org" <dnsop@ietf.org>
In-Reply-To: <20171115032700.GE94801@registro.br>
Message-ID: <alpine.LRH.2.21.1711142303220.29343@bofh.nohats.ca>
References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <b21647d7-a710-e5f7-048f-d90eccc79c0f@nic.cz> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> <20171115032700.GE94801@registro.br>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1yrRE_gQPIUxgb7qaXFVCKOwICk>
Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 04:11:09 -0000
On Wed, 15 Nov 2017, Frederico A C Neves wrote: > Yes. And add to that cases were TLDs rolled just before adding to the > root. So what is the security model then? Let's say .example rolled and now has a bad DS. Someone overrides this with a local trust anchor so the domain does not go dark. - How do you know the roll was legitimate? - How does an application make a security decision about a found TLSA record that depends on this trust anchor? Now .example rolls to yet another key to fix their mistake and updates the DS. - How does the application know the roll is legitimate? - How does an application make a security decision about a found TLSA record that depends on this trust anchor? - Who, why and when does the local trust anchor get deleted. What if _this_ is the key that example.com lost the private key to? Now same as above, but one of these rolls were done by an attacker and is malicious. Trusting "any"thing is just a path to madness. Paul
- [DNSOP] Configured Trust Anchor vs. DS record Edward Lewis
- Re: [DNSOP] Configured Trust Anchor vs. DS record Petr Špaček
- Re: [DNSOP] Configured Trust Anchor vs. DS record Evan Hunt
- Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs.… Edward Lewis
- Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs.… Paul Wouters
- Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs.… Paul Vixie
- Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs.… Paul Wouters
- Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs.… Edward Lewis
- Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs.… Frederico A C Neves
- Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs.… Paul Wouters
- Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs.… Edward Lewis