Re: https at ietf.org

Ted Lemon <ted.lemon@nominum.com> Mon, 25 November 2013 17:24 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 42FD61ADF64 for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 09:24:36 -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 8eEEy7xapmqE for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 09:24:35 -0800 (PST)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id E31571ADF62 for <ietf@ietf.org>; Mon, 25 Nov 2013 09:24:34 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUpOH0/dq2+XphKz4u/9RZZOfr//gga8V@postini.com; Mon, 25 Nov 2013 09:24:35 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 DAB441B8165 for <ietf@ietf.org>; Mon, 25 Nov 2013 09:24:34 -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 B918B19005C; Mon, 25 Nov 2013 09:24:34 -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:24:34 -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: <5F81A229-9121-478C-9D17-D65FB72FFABF@virtualized.org>
Date: Mon, 25 Nov 2013 12:24:31 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <35EADAA5-4368-4AC7-A1E8-5566BAD5294C@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>
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:24:36 -0000

On Nov 25, 2013, at 12:11 PM, David Conrad <drc@virtualized.org> wrote:
> What does that mean?  Exactly what threat are you imagining an NSL would be used to hide? 

Hi, this is the FBI, we would like a copy of the DNSSEC root private key please, and don't tell anyone you gave it to us.   The same attack would work on .com as well, of course, without bothering with the root key.

To be clear, this is a threat that can be addressed, but we should be thinking about it as part of the threat model when talking about replacing CA PKI with DANE.   In point of fact, I would argue that the two certificate hierarchies have different threat models, and that we ought to keep both and use them for cross-validation where appropriate, not just throw all our eggs in a different basket and hope for the best.