Re: https at ietf.org

Ted Lemon <ted.lemon@nominum.com> Mon, 25 November 2013 17:45 UTC

Return-Path: <Ted.Lemon@nominum.com>
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 441781ADF80 for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 09:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 XsDy_icBlRS5 for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 09:45:49 -0800 (PST)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 58CBD1ADEB1 for <ietf@ietf.org>; Mon, 25 Nov 2013 09:45:49 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUpOMzUIrTYWi7YYhOXDoymZax3nCnr5P@postini.com; Mon, 25 Nov 2013 09:45:49 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 58ACF1B8165 for <ietf@ietf.org>; Mon, 25 Nov 2013 09:45:49 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 52CA619005C; Mon, 25 Nov 2013 09:45:49 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 09:45:49 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: https at ietf.org
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <C3889E2F-FE93-4B61-887B-47ECDD2707A1@virtualized.org>
Date: Mon, 25 Nov 2013 12:45:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <5E4F2B19-4C8A-4E91-B005-5AB6E5BB6C51@nominum.com>
References: <CAHBU6ivbrk=NXgd4_5Upik+8H0AbHRy3kJnN=8fcK+Bz3pOV9Q@mail.gmail.com> <alpine.LRH.2.01.1311051733570.4200@egate.xpasc.com> <01P0FR4HDQNG00004G@mauve.mrochek.com> <CAHBU6ivZS33r4HHbCC391Ug9fMtZkJ3nojEeeqH5L+0+o3ZqGQ@mail.gmail.com> <01P0FU0CS96Q00004G@mauve.mrochek.com> <26C6A672-A5D2-44C4-B343-9CCE5E388348@standardstrack.com> <CAKHUCzzzT-0p89uT62zrxGqF1XACG+Ok7hNLcuTaDad7R7eCTQ@mail.gmail.com> <527C2233.3030605@cis-india.org> <CAKHUCzzcNros1=O=D1zkEU1n+XdRcdYdgK2Hkik=AvxbuUJX3w@mail.gmail.com> <731D4B97-BC19-4AC8-BEF6-DA702073069A@standardstrack.com> <A1F7405B-CD8D-4DB8-9817-71F29AE14266@hopcount.ca> <E760A0D0-57E1-44F5-AF0C-32F87E4C55FF@nominum.com> <5F81A229-9121-478C-9D17-D65FB72FFABF@virtualized.org> <35EADAA5-4368-4AC7-A1E8-5566BAD5294C@nominum.com> <C3889E2F-FE93-4B61-887B-47ECDD2707A1@virtualized.org>
To: David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.1822)
X-Originating-IP: [192.168.1.10]
Cc: IETF-Discussion Discussion <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 17:45:51 -0000

On Nov 25, 2013, at 12:33 PM, David Conrad <drc@virtualized.org> wrote:
> Ignoring the fact that the private key is stored in an HSM with multiple layers of protection that requires a number of people to even get into the room in which the cage that holds the safe which contains the HSMs are stored, what _exactly_ would the FBI _do_ with the private root key?

The root key (or a TLD key) can be used to create a fake hierarchy, nearly identical to the real hierarchy, but with a few changes.   Install this on a few targeted name servers and you can install fake DANE certs that validate.   If you did this in a pervasive manner, it would be easy to detect, but only if we are checking.   For targeted attacks, it's still probably possible to defend against it, but a DNSSEC validator that could detect that it might be under such an attack would be a fun challenge and would require some careful thinking.

Actually, getting a TLD key like the .COM key would make for a more effective attack, since it's fairly easy to cache all the TLD keys and notice weird changes to them, but it's a lot harder to cache keys for all the registered domains you might ever visit.

My point is simply that we can't just wave our hands and say "DANE" and be satisfied.   If we put all our eggs in the DNSSEC basket, we need to think about what threats that exposes us to, and address those threats.   Simply checking the signatures proves nothing if the trust anchor(s) we use to check have been compromised.