Re: [TLS] OCSP Must Staple

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 28 October 2013 16:17 UTC

Return-Path: <alexey.melnikov@isode.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 0608F11E8283 for <tls@ietfa.amsl.com>; Mon, 28 Oct 2013 09:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.892
X-Spam-Level:
X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 5sivQOa5vYCQ for <tls@ietfa.amsl.com>; Mon, 28 Oct 2013 09:17:04 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id B9A3511E827B for <tls@ietf.org>; Mon, 28 Oct 2013 09:17:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1382977021; d=isode.com; s=selector; i=@isode.com; bh=5iGlyyFKyE+pUuZ63oaM/iOYY42f22dQ78ogI69Hmb8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=w93hsiTExnjpENahFao4LlWClvwfk5xBkksTXMXM5nsJZ83iDEpRGiHbyT3Qayup1A4PcU uIfnSRwTfWk7xLBeB1J1ynl/HeMMEFBzs+QXEh6QM0hbXrTzBYapz4iV0t9lGEwWOzLOsB IUjSOyNFc94WHtUqtgCTBE7fm3ZH0YE=;
Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id <Um6N9QBBXKjO@waldorf.isode.com>; Mon, 28 Oct 2013 16:17:01 +0000
Message-ID: <526E8DF3.8060506@isode.com>
Date: Mon, 28 Oct 2013 16:16:51 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
To: Phillip Hallam-Baker <hallam@gmail.com>
References: <CAMm+LwhG9FVEhRBUO5EqKUzGGLb3h3ZzxzgJobrAborn6Me83w@mail.gmail.com>
In-Reply-To: <CAMm+LwhG9FVEhRBUO5EqKUzGGLb3h3ZzxzgJobrAborn6Me83w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] OCSP Must Staple
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: Mon, 28 Oct 2013 16:17:07 -0000

On 23/10/2013 14:46, Phillip Hallam-Baker wrote:
> We have been discussing MUST staple for quite some time. The ADs would 
> like to know if there is support for adding this feature to certificates.
>
> The draft I wrote is designed to be agile so that it covers all new 
> OCSP stapling like ideas rather than just being a one off. But it is 
> pretty simple:
>
> http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02
>
>
> The advantage of MUST staple is that if a client receives a TLS cert 
> chain with MUST Staple and no OCSP token then it can refuse the 
> connection and hard fail rather than attempting to retrieve the token 
> and soft failing.
>
> This allows for a performance improvement and a security improvement.

I read the draft and this work looks interesting to me.