IETF Logo Mail Archive

Re: [TLS] New version of Multiple OCSP mode of Certificate Status extension

"Brian Smith" <brian@briansmith.org> Wed, 28 July 2010 21:03 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24D63A6925; Wed, 28 Jul 2010 14:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level:
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKb9BpluVrWs; Wed, 28 Jul 2010 14:03:29 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id CA0633A684A; Wed, 28 Jul 2010 14:03:28 -0700 (PDT)
Received: from T60 (unknown [98.200.150.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C909509E3; Wed, 28 Jul 2010 17:03:45 -0400 (EDT)
From: Brian Smith <brian@briansmith.org>
To: agl@google.com, yngve@opera.com
References: <op.u87n4tthqrq7tp@acorna> <op.vghzp61ivqd7e2@killashandra.oslo.osa> <AANLkTikh0EL0DygFFKC8L-Z406C_HsfatVSbti_Ur9x9@mail.gmail.com>
In-Reply-To: <AANLkTikh0EL0DygFFKC8L-Z406C_HsfatVSbti_Ur9x9@mail.gmail.com>
Date: Wed, 28 Jul 2010 16:03:44 -0500
Message-ID: <002101cb2e98$60d77230$22865690$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLMt6AH1k71n+68rUsiHq+hip1tpwGaMZvQAZA7Rw8DAkQgow==
Content-Language: en-us
Cc: pkix@ietf.org, tls@ietf.org
Subject: Re: [TLS] New version of Multiple OCSP mode of Certificate Status extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Wed, 28 Jul 2010 21:03:30 -0000

Adam Langley wrote:
> On Tue, Jul 27, 2010 at 6:35 AM, Yngve Nysaeter Pettersen
> <yngve@opera.com> wrote:
> > Based on the ongoing PKIX discussion about an update of OCSP, I
> > (finally) realized the the problem my multiple-ocsp TLS extension is
> > designed to fix can be fixed in another way, by adding an OCSP
> > extension instead.
> 
> I would welcome not having to change TLS to support multiple
> OCSP responses.
> 
> However, with TLS changes, we can deploy without any action on
> the part of the OCSP responders. That makes it a possibility. If we
> are beholden to updating the responders then I fear that it'll never
> happen.

Plus, it is a privacy issue. If you rely on the CAs to provide this
extension in their OCSP responses, then any CAs that want OCSP traffic (for
user tracking) can just omit the OCSP extension. The multiple OCSP method
lets the server improve the user's privacy without any cooperation from the
CAs involved.

(Most TLS clients issue their OCSP requests before they've
authenticated the server's Certificate and (lack of) CertificateStatus
messages, so while a CA wouldn't be able to force clients to make the OCSP
requests, a MiTM can still force them to do so. This could be prevented
by moving the CertificateStatus and CertificateRequest before the
ServerKeyExchange, and making the ServerKeyExchange signature work like the
CertificateVerify signature, hashing all the prior handshake messages. This
is something that should be considered for extensions like Snap Start that
modify the structure of the handshake, and for the next versions of TLS).

Regards,
Brian

v2.23.0 | Report a Bug | By Email