Re: https at ietf.org

David Conrad <drc@virtualized.org> Mon, 02 December 2013 22:28 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 092811ADF33 for <ietf@ietfa.amsl.com>; Mon, 2 Dec 2013 14:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uUGNbmEhg_Te for <ietf@ietfa.amsl.com>; Mon, 2 Dec 2013 14:28:43 -0800 (PST)
Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6B57A1ADF12 for <ietf@ietf.org>; Mon, 2 Dec 2013 14:28:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id C1B5C863CD; Mon, 2 Dec 2013 17:28:40 -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 86510-06; Mon, 2 Dec 2013 17:28:40 -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 E0AD2863C6; Mon, 2 Dec 2013 17:28:39 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_898F762C-6551-4B20-A557-5AC600E83114"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: https at ietf.org
From: David Conrad <drc@virtualized.org>
In-Reply-To: <CAMm+LwhF5-nEdM0Rjh1XtK1X=_xo6GkqPnZgfGaCEJ19g8ULrg@mail.gmail.com>
Date: Mon, 02 Dec 2013 14:28:37 -0800
Message-Id: <0AE13719-B6E4-4715-BB04-CCEDF90ED2F9@virtualized.org>
References: <20131125180608.55454.qmail@joyce.lan> <E5836934-317D-4E73-80CC-B8847047852A@virtualized.org> <CAMm+LwhXb6uYJLie1FmJE34aC0EO39_t7331X1O0iD=-gmSEvw@mail.gmail.com> <38B94CB1-C62A-4BAC-85D4-B08FB7315CE9@virtualized.org> <CAMm+LwhF5-nEdM0Rjh1XtK1X=_xo6GkqPnZgfGaCEJ19g8ULrg@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: Apple Mail (2.1822)
Cc: IETF Discussion Mailing List <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, 02 Dec 2013 22:28:45 -0000

Phillip,

On Dec 2, 2013, at 1:02 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> [...]


At no point did I suggest the key management processes were unique to ICANN nor did I suggest ICANN invented any of the processes out of thin air nor did I make any statement regarding the viability of online vs. offline signing of TLDs or the root or that the processes need be the same. You appear to be having a different conversation than the one Ted and I were engaging in and are attributing to me assertions I did not make (and don't necessarily agree with). I'm unclear how this is helpful.

My complaint was simply that I believe it is more useful to describe actual attacks and the vulnerabilities that allow for those attacks than it is to say "NSL" as if it a secret decoder ring.  Feel free to disagree with that complaint.

> In that respect an NSL is unique to US jurisdiction, contrary to claims made by some. It is a warrantless search order. 

I would be surprised to discover the US is unique in allowing the existence of warrantless search orders under the guise of national security, however that does not appear to be relevant to this particular thread.

>> The point is that unlike the operation of (many? most? all?) commercial CAs, the operation of the root KSK by ICANN is public and open for input/improvement. As I said in a previous message "send text".
> Every CA is required to publish a CP and CPS. These are public documents.

I was not talking about the documents, I was talking about the actual operations. As you've indicated in the Diginotar case "... the audit did not actually cover the public CA which it was used to gain inclusion in the root programs." Since as far as I know, _all_ handling of the root key by ICANN is done in a public way (see http://data.iana.org/ksk-ceremony/15/ for the recordings of the most recent key ceremony), I'm asking how would ICANN "turn Diginotar"?

Regards,
-drc