Re: [dane] Manipulation of DNSSEC by US government possible? (was Re: Comments on draft-wouters-dane-openpgp-02)

Rene Bartsch <ietf@bartschnet.de> Thu, 31 July 2014 17:36 UTC

Return-Path: <ietf@bartschnet.de>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88DF1A02E3 for <dane@ietfa.amsl.com>; Thu, 31 Jul 2014 10:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.348
X-Spam-Level:
X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, SPF_PASS=-0.001] autolearn=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 mAAyMz9E9uqs for <dane@ietfa.amsl.com>; Thu, 31 Jul 2014 10:36:42 -0700 (PDT)
Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (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 884C31A026F for <dane@ietf.org>; Thu, 31 Jul 2014 10:36:41 -0700 (PDT)
Received: (qmail 12646 invoked from network); 31 Jul 2014 17:36:37 -0000
Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 31 Jul 2014 17:36:37 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Thu, 31 Jul 2014 19:36:34 +0200
From: Rene Bartsch <ietf@bartschnet.de>
To: dane WG list <dane@ietf.org>
In-Reply-To: <alpine.LFD.2.10.1407311106440.6673@bofh.nohats.ca>
References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <alpine.LFD.2.10.1407280941250.30319@bofh.nohats.ca> <e2a23385d5698a1022b201915817ed40@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> <CFFE5FC9.4D653%gwiley@verisign.com> <20140730132106.432C11B1536F@rock.dv.isc.org> <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> <alpine.LFD.2.10.1407311106440.6673@bofh.nohats.ca>
Message-ID: <75c3ef7eef38c9d621b9e69976865d26@triangulum.uberspace.de>
X-Sender: ietf@bartschnet.de
User-Agent: Roundcube Webmail/1.0.1
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XsXs-Q4HbYB3Q1XFyCXiFcynk6k
Subject: Re: [dane] Manipulation of DNSSEC by US government possible? (was Re: Comments on draft-wouters-dane-openpgp-02)
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jul 2014 17:36:43 -0000

Am 2014-07-31 17:10, schrieb Paul Wouters:
> On Thu, 31 Jul 2014, Rene Bartsch wrote:
> 
>> It seems DNSSEC/DANE helps against most hackers and attackers but 
>> cannot protect from attackers which have access to both the trust 
>> anchor keys and routing infrastructure.
> 
> Whom do you trust? "No one" is not a valid answer.

http://en.wikipedia.org/wiki/Bundesnachrichtendienst#History

In global communication I only trust mathematically proven algorithms. 
But don't worry, I trust people I've known for years personally. ;-)

> The best we can do is
> audit/log the KSKs and do some kind of "N of M" verification that such
> keys are in the public world view. Of course, that leads to small
> outages during rollovers....
> 
>> Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with 
>> resolver software?
> 
> Of course. That's not so much a matter of protocol but of local policy.
> 
> Paul

In hierarchical architectures we always have a more or less trustworthy 
anchor. So we should clearly describe the security limitations in the 
security considerations section. Real security has to wait until the 
next evolution step of the internet (maybe blockchains?).

Renne


-- 
Best regards,

Rene Bartsch, B. Sc. Informatics