Re: [TLS] Call for acceptance on multi-stapling

Kyle Hamilton <aerowolf@gmail.com> Thu, 19 April 2012 01:06 UTC

Return-Path: <aerowolf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BA011E80AD for <tls@ietfa.amsl.com>; Wed, 18 Apr 2012 18:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 YoXWJ8YYbYZA for <tls@ietfa.amsl.com>; Wed, 18 Apr 2012 18:06:40 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7112911E809D for <tls@ietf.org>; Wed, 18 Apr 2012 18:06:38 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so7366651bku.31 for <tls@ietf.org>; Wed, 18 Apr 2012 18:06:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hxJnsmElDfDXNPm4678EOQOzC6201ADPj4O2URlMa/g=; b=AuonCnxzMsrpvkfnf2vgbYx1LAsarAV7JzqKvRFG5/sJwlsJDPhaQRW2w6P6uUKEou Q2qTh57eD5CotyM8D/Cdt7hJwJHqW+Pc2kDYD+QRC9qLtcj/lJiUlM4F6ZybE1TCFq4w v4uyFoagH26G0BbLUX/ePoE0rJFr1YwfsjWkB+bE/2+ZQ4+JAE87+EeFjDk9Ln9Zpynj /vZWt7BWX3OZcZX+UJyBCAPWF91ZJNisdu2PeD1hYaFiGliTrZSRytGe1ew4DXHHXpsm CTeTgZjRS1RVXvBees5w9GP5qkBBlTPdlrGRYclpKE42nrUGWJFLvgwv3f0+HNaA3fDD 7nHA==
MIME-Version: 1.0
Received: by 10.204.156.141 with SMTP id x13mr33204bkw.50.1334797597369; Wed, 18 Apr 2012 18:06:37 -0700 (PDT)
Received: by 10.204.17.70 with HTTP; Wed, 18 Apr 2012 18:06:37 -0700 (PDT)
In-Reply-To: <CABcZeBOz6T6mb5Hy9jfhRHkWxusccGmr2vjrah9aRTBC2kCmuQ@mail.gmail.com>
References: <CABcZeBOz6T6mb5Hy9jfhRHkWxusccGmr2vjrah9aRTBC2kCmuQ@mail.gmail.com>
Date: Wed, 18 Apr 2012 18:06:37 -0700
Message-ID: <CAPMEXDam=9U0LFaieRYYCxGMRdX13uKd7j4CrczkY2YE0v1NSg@mail.gmail.com>
From: Kyle Hamilton <aerowolf@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Cc: tls@ietf.org
Subject: Re: [TLS] Call for acceptance on multi-stapling
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Apr 2012 01:06:45 -0000

On Wed, Apr 18, 2012 at 2:02 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> WG members,
>
> At the meeting in Paris there was broad consensus to adopt Yngve's
> TLS Multi-Stapling draft
> (http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt).
>
> The WG chairs would like to confirm this consensus. Please send any
> comments by Wednesday April 25.

I believe that this is improper for TLS-WG to take up.  The problem
that multi-stapling is intended to address can be done completely
within an X.509 self-signed structure, and derives from PKIX-WG not
producing a single coherent standard that client protocols can simply
plug in.  Trying to work around a PKIX-WG problem in TLS is not going
to solve the same types of problems that exist in all other PKIX
client protocols.

If PKIX-WG could get its collective head out of its... darkness... I'd
say push this over there, and force them to come up with a real single
atomic credential format that can securely support asserting multiple
certificate chains, stapled OCSP responses for ALL certificates in ALL
chains, multiple timestamps... basically, TLS has one place to assert
one keypair.  All we need is a signature chain (or multiple signature
chains) to say that someone (an identified X.509 principal, not an
X.509 device) actually *gasp* used their own authority to assign a key
to a device.

That we can't do this is a bug in PKIX, not a bug in TLS.  That we
can't get multiple certificate status responses in a single structure
is a failure of PKIX, not TLS.  Working around it in TLS-WG is
inefficient, and will not solve the same problem in other PKIX client
protocols.

Unfortunately, because PKIX-WG can't/won't do anything because
everybody's too afraid of changing the status quo, this seems to be
the only effective option that presents.  I would prefer that it not
be handled here, but since the problem in PKIX (which won't change) is
exposed by TLS...

I (grudgingly) shall support this, with many reservations.

-Kyle H