Re: https at ietf.org

David Conrad <drc@virtualized.org> Mon, 25 November 2013 23:22 UTC

Return-Path: <drc@virtualized.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7101ADFE1 for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 15:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.903
X-Spam-Level:
X-Spam-Status: No, score=-3.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ZcuisOhm8HGH for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 15:22:09 -0800 (PST)
Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 26B881AE051 for <ietf@ietf.org>; Mon, 25 Nov 2013 15:22:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 65B6A85D7C; Mon, 25 Nov 2013 18:22:08 -0500 (EST)
Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 47964-06; Mon, 25 Nov 2013 18:22:08 -0500 (EST)
Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id B31F885B80; Mon, 25 Nov 2013 18:22:07 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_CFCF59A7-65F2-4C65-973A-9E19725899BF"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: https at ietf.org
From: David Conrad <drc@virtualized.org>
In-Reply-To: <20131125180608.55454.qmail@joyce.lan>
Date: Mon, 25 Nov 2013 15:22:06 -0800
Message-Id: <E5836934-317D-4E73-80CC-B8847047852A@virtualized.org>
References: <20131125180608.55454.qmail@joyce.lan>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.1510)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2013 23:22:11 -0000

On Nov 25, 2013, at 10:06 AM, John Levine <johnl@taugh.com> wrote:
>>> Is the DNSSEC root key secure against National Security Letters?
>> What does that mean?  Exactly what threat are you imagining an NSL would be used to hide? 
> Hijack someone's DNS traffic, provide a chain of fake servers pointing
> to a fake mail or web host, all with valid DNSSEC.

As I'm sure you're aware, for this attack to work, not only would the US government need to compromise the root KSK HSMs and a rather Byzantine set of safeguards, they would also presumably need to do so in a way that would reduce the likelihood that the compromised elements would be noticed.  Since the data is public, this might be a bit tricky -- forcing the attack to occur as close to the target as possible to minimize the chances some non-target would notice (which, if it were noticed, would like result in the absolute worst possible case in DNSSEC-land, the need to do an emergency role of the root KSK in every resolver on the planet: something we still don't know how to do). Since the attack would already be down near the validating resolver, I suspect it would be _far_ easier and infinitely less risky to compromise that validating resolver (particularly if that resolver is operated by a third party, like it is for the vast majority of folks -- something I've long felt is fundamentally broken).

> I guess that we need to ask the same question about TLDs that are
> hosted in the United States.  

I would be surprised if only the US has NSLs.

> That would mostly mean Verisign, Afilias and PIR, and Neustar.

ICANN went to significant lengths to make everything done with the KSK extremely well documented and as public as humanly possible. I personally don't know what those organizations do (mostly because I haven't looked) but would be surprised if the level of disclosure is close to what ICANN has done.  As such I feel Joe's response to Ted:

>>>> Sounds like a good question to ask ICANN.

was wrong. Professional Operational Security folk should review the root KSK DPS (https://www.iana.org/dnssec/icann-dps.txt) and identify any weaknesses, including any vulnerabilities to NSL-like attacks so those weaknesses can be remedied. Simply waving "NSL" around like a magic wand is unhelpful.

Regards,
-drc