Re: https at ietf.org

Joe Abley <jabley@hopcount.ca> Tue, 26 November 2013 02:44 UTC

Return-Path: <jabley@hopcount.ca>
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 E5ECC1AE0AB for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 18:44:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.001
X-Spam-Level:
X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 l6TK_WBPih2L for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 18:44:53 -0800 (PST)
Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F06951AE134 for <ietf@ietf.org>; Mon, 25 Nov 2013 18:44:52 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id i13so3886780qae.3 for <ietf@ietf.org>; Mon, 25 Nov 2013 18:44:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=kUDJPBztKng2Hms5JomHRIMlMtcOKFSjoHTWB70Vkp4=; b=pZwJrT/NvFsFk8x3G0OR1U9Ti+dfQA0HjenHyyfTObFUmBpmifCx1KZSabMX3hagZO 6cNHVaH/+T6Ap9RVqBgZgNIg2P6eUTfYtMymDSuB+KrR7u5rGtn/WNTJdhRAedqgjJ0J ZMmy6JBhICArEGlIdXtUdmS3pGqpivD6feyBM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding:content-disposition; bh=kUDJPBztKng2Hms5JomHRIMlMtcOKFSjoHTWB70Vkp4=; b=KvdopifkOPBsU7k/mjt2E2d+qTzg0a0y4o9bcY2VrtJuhp98RKBYQRyS5uEz+brq06 5tfghVmr6OQLDkMdnf/pgVElQC5SJWN44DMB9Q1+jx1e0A+IZVGFYLbSZDZ6Oti4wgHq l9C6R3Ou0YRD7d268k2e9qaDWwxodHbar7wEa1HNWiVNZ7EhSvpMavY+BRzeFAgu4DMv TWul5R7P7S55AVTThI7vOp4aH65GUa+pSeEiMlDj9V+n8PGBmqJNVJ54jkl8fmhJ8zEH rmU0ZNA0GAqwqlpNOMr3QD2VgXSKzARt3UXPYnyfYsm7EJCHLsIW26Cbbn/Hva3nVDI/ UFMQ==
X-Gm-Message-State: ALoCoQknS1Ci+sGrbqt3wwSK7jHXFfJdA4B2aaEhYl0GniNVFvWlro/jS7diWGAh93o9mxZz7l7l
X-Received: by 10.224.54.194 with SMTP id r2mr52271135qag.57.1385433892880; Mon, 25 Nov 2013 18:44:52 -0800 (PST)
Received: from [2001:4900:1042:1::] ([2001:4900:1042:1:e15f:b548:8134:aa24]) by mx.google.com with ESMTPSA id x10sm41750618qas.5.2013.11.25.18.44.50 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 25 Nov 2013 18:44:51 -0800 (PST)
Date: Mon, 25 Nov 2013 21:44:50 -0500
From: Joe Abley <jabley@hopcount.ca>
To: Randy Bush <randy@psg.com>
Message-ID: <D34CD612BB484350BB5D2937CF8DE2D9@hopcount.ca>
In-Reply-To: <m2r4a3lxvk.wl%randy@psg.com>
References: <20131125180608.55454.qmail@joyce.lan> <E5836934-317D-4E73-80CC-B8847047852A@virtualized.org> <m2r4a3lxvk.wl%randy@psg.com>
Subject: Re: https at ietf.org
X-Mailer: sparrow 1.6.4 (build 1178)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: IETF Disgust <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: Tue, 26 Nov 2013 02:44:55 -0000

On Monday 25 November 2013 at 21:06, Randy Bush wrote:
> seems to me that if the amazingly elaborate ceremonies around the root
> key do not include m of n needed to open the bottle, with the m and n
> distributed among multiple national juristictions, it is merely security
> theater.


Yes, that was what I was getting at.

The quarterly ceremonies are conducted to provide transparency and accountability for the desired, intended processes during which the KSK is necessarily exposed in order to generate signatures (and other key operations).

Safeguarding the process by which signatures are made is important, and so I would not describe the ceremonies as theatre -- but they are not a complete picture of the protection afforded to the KSK.

In between ceremonies, the copies of the KSK and the credentials by which an HSM can be brought on-line should remain in their respective safes. There is no international panel of trusted witnesses to that, nor could there reasonably be (I wouldn't trust anybody who volunteered to sit in an empty machine room for 361 days of the year watching nothing happen).

ICANN has gone to great lengths with internal process and involvement of external auditors (who scrutinise not only the provided documentation for ceremonies and any other operational access to facilities that was required) but who also consider compensatory controls such as unbroken CCTV footage from facility providers, interviews with relevant staff, alarm logs within the key management facility (and as retrieved from the separate, external central station), access logs at the front security desk, etc.

This is all public information, and has been well described in operational forums globally since around 2009.

Shenanigans with the KSK between ceremonies would involve collusion between ICANN staff, auditors, facility staff, central station staff, and potentially others. In ordinary times I would expect all of there to be too much reputational risk individually and across the board for anybody to even consider acting out of turn. However, these are all American companies, and I don't know how to tell whether they have all individually been instructed to act and conceal their action by order of law.

I recall one American company recently who has started making a point of confirming that they have not been subject to any national security letters in their annual reports, the idea being that they would be unable to make such an assertion if the reverse was true; the precedent and routine facilitates future disclosure-by-omission. Perhaps some or all of these companies might consider doing the same thing.

Anyway, cutting to the chase, despite the fact that I believe the system as a whole is about as well-designed as could be done within the requirements, I think the original question is still reasonable and is still one that should be asked of ICANN. I imagine they would enjoy giving a satisfactory response. The staff concerned are also professional and diligent members of this community and have a track record of welcoming and incorporating change from good suggestions.


Joe