[therightkey] Why the focus on The?

"Kyle Hamilton" <aerowolf@gmail.com> Fri, 27 January 2012 21:02 UTC

Return-Path: <aerowolf@gmail.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855CC21F84C4 for <therightkey@ietfa.amsl.com>; Fri, 27 Jan 2012 13:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.723
X-Spam-Level:
X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Klkx9Ct5uwS7 for <therightkey@ietfa.amsl.com>; Fri, 27 Jan 2012 13:02:36 -0800 (PST)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBF7321F856F for <therightkey@ietf.org>; Fri, 27 Jan 2012 13:02:35 -0800 (PST)
Received: by dado14 with SMTP id o14so2037573dad.31 for <therightkey@ietf.org>; Fri, 27 Jan 2012 13:02:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:date:message-id:subject:mime-version:content-type; bh=z9AcfJupLbLYcUbEuk9pybfHuRXzUyDfBYjSLaU33GI=; b=Ab0/EW9FB+Nx274sMdSX/9st3JMzbIlHcwV7o/wCUaYFPBZ3cweAZCVBG6h9adJIF/ 8p0AmsypyDUbhXM5B1HPHYzBI8hsKFRvxR9jbcaEWnXvOmbmjez3Y7yKVGyJU1++GgwS 8MRLVTrY7jbGnGX/aHFcrJdrtvt1bZE1bYgXs=
Received: by 10.68.218.231 with SMTP id pj7mr14303169pbc.63.1327698155782; Fri, 27 Jan 2012 13:02:35 -0800 (PST)
Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id a5sm22714070pbh.15.2012.01.27.13.02.33 (version=SSLv3 cipher=OTHER); Fri, 27 Jan 2012 13:02:34 -0800 (PST)
From: Kyle Hamilton <aerowolf@gmail.com>
To: therightkey@ietf.org
Date: Fri, 27 Jan 2012 13:02:24 -0800
Message-ID: <gxxp70uorq8dbvsnebjezwJv4X.penango@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="gmsm1.9.4eqgxxp70vd6vr92qerb62"
Subject: [therightkey] Why the focus on The?
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jan 2012 21:02:36 -0000

All,

Why are we focusing on 'the' anything?

Key pinning and CA pinning don't work with only One True Key.  The only usable way to do that kind of thing is to present multiple options.  As certificate chains expire or are discovered to be revoked, those keys would be removed from the list of acceptable keys.

We have multiple data paths to the user, and everything that isn't security-related in IETF is recommended as highly redundant.  Why is the security area different, where everything is so singular and brittle?

We should be providing multiple TXT records with hashes of multiple acceptable SPKIs, and cross-referencing them with the SPKIs we receive in the TLS handshake.  We should not, however, rely on this as 'the' way to get information around.  That information should be advisory unless no certificate chain is presented by the server.  (i.e., you can be advised that you should look for certain keys, and you can also be willing to trust a certifier.  These are not mutually exclusive.)

We do indeed need certification, and certification does provide a useful service.  It just doesn't do it right now.  The problem is the way it's implemented, preventing it from being useful.  Implementors don't want to spend the time and make the changes to make it more useful, or are too stubbornly attached to an unworkable model to realize that they need to change.

We should also provide more than one certificate chain in our handshakes.  This would permit maintenance of the certificates on the webservers to be moved to a scheduled maintenance window instead of "OMG our CA is about to be delisted we have to act NOW".  It would also permit different certificate chains to be presented for different applications without having to define a new TLS extension.

Why is everything so single-point-of-failure in the Security working area?  Does it really have to be?

-Kyle H