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

Paul Wouters <paul@nohats.ca> Mon, 28 July 2014 16:14 UTC

Return-Path: <paul@nohats.ca>
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 0C21A1A038E for <dane@ietfa.amsl.com>; Mon, 28 Jul 2014 09:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 mc256Ht2c1O4 for <dane@ietfa.amsl.com>; Mon, 28 Jul 2014 09:14:08 -0700 (PDT)
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 ietfa.amsl.com (Postfix) with ESMTPS id DAD801A038C for <dane@ietf.org>; Mon, 28 Jul 2014 09:14:07 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5EB88813B2; Mon, 28 Jul 2014 12:14:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1406564046; bh=osq/JeUZkun8fO+J7UmrQN4leH31eQ7FUV9pXXfnzyI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NY30PDlSNKxFT7h7iEwkHfA7tp7c1TYDLNlWozhGOtOc/8tYxkyKd6HIXw5UjWqmN Y8rKy2hGJNE3xxefnRXWphMjZNcpFO2kFmZWpF7ThUolCqmydfmVAfCoXWCJo2+aDK +EyEJoKIJZbBZdd+GRH+YnPkOI47maom4axxiMAs=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6SGE51n012924; Mon, 28 Jul 2014 12:14:06 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 28 Jul 2014 12:14:05 -0400
From: Paul Wouters <paul@nohats.ca>
To: Rene Bartsch <ml@bartschnet.de>
In-Reply-To: <e2a23385d5698a1022b201915817ed40@triangulum.uberspace.de>
Message-ID: <alpine.LFD.2.10.1407281211180.12270@bofh.nohats.ca>
References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <alpine.LFD.2.10.1407280941250.30319@bofh.nohats.ca> <e2a23385d5698a1022b201915817ed40@triangulum.uberspace.de>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/An5VOpqTOjDQ8cRPPkBPRAHJTB4
Cc: dane@ietf.org
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: Mon, 28 Jul 2014 16:14:09 -0000

On Mon, 28 Jul 2014, Rene Bartsch wrote:

> Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see how it 
> would help. Consider the following case:
>
> (Forced by secret US law) The IANA secretly hands over the current private 
> key of the DNSSEC trust anchor to a US government agency which uses the 
> private key to sign forged zones and feeds them to DNS resolvers. That way US 
> government agencies would be able to manipulate any DNS record including 
> OpenPGP while users would be lulled in a false sense of security.
>
> In case I didn't miss any super-security feature users should be aware of 
> that fact.

An audit log or reputation system would prevent the user from believing
a signed answer by a different "good" key. For the USG to take over your domain,
for which they do not have the private key, they need to take over the
parent domain and change the key listed there. That change can be
detected by you.

Paul