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