Re: [TLS] draft-hallambaker-tlsfeature-02

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 29 May 2013 07:58 UTC

Return-Path: <n.mavrogiannopoulos@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 E591121F9133 for <tls@ietfa.amsl.com>; Wed, 29 May 2013 00:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 kvoQMQW+GG-x for <tls@ietfa.amsl.com>; Wed, 29 May 2013 00:58:12 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0307321F8756 for <tls@ietf.org>; Wed, 29 May 2013 00:58:11 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id p58so6168553wes.35 for <tls@ietf.org>; Wed, 29 May 2013 00:58:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=PWzD4/ZIdoktGdsExxN+C48XbVMXX8legs/JeI+5BaE=; b=luGZidd99xft/UurXWu6QrK+M40BU778jqKm7AtPYnIzU8ZL73DnE33y+trC9r+V7X 68nXVSUZ9uoWO752xKZMr3AV1v/C72y42rm8G7Kbah/s1zCYVYZOEgyZ2oewiR57/lFz dKiLdHj4oFQo8BXjsGWliNNs37PmI8a2i3q4dINP4a5BYjZCaXWD17jB1Nqa4kmhmylc tYJIKi1h9sGY3NDhW5qmTZ9RUxmstX/hYvzHJbRFeSGDjK1QOLssRbSAgHZEKwS2MQpW nyHm0fzIHBcJ8B3OM65lmuHuCfe4bFyoxC4k5maA4uLRaUHRE0hrK0mY8v4Ar7EPk/MA 1jpw==
X-Received: by 10.194.8.163 with SMTP id s3mr1220015wja.41.1369814291141; Wed, 29 May 2013 00:58:11 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id eq15sm29362138wic.4.2013.05.29.00.58.09 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 00:58:10 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <51A5B50B.8080205@gnutls.org>
Date: Wed, 29 May 2013 09:58:03 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: tls@ietf.org
References: <01af01ce5bc6$67b9b8c0$372d2a40$@digicert.com>
In-Reply-To: <01af01ce5bc6$67b9b8c0$372d2a40$@digicert.com>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] draft-hallambaker-tlsfeature-02
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: Wed, 29 May 2013 07:58:13 -0000

On 05/28/2013 07:11 PM, Ben Wilson wrote:

> What if the CA / Browser Forum were to add an optional provision for the
> certificate profile of End Entity TLS Certificates that said the following?
> 
> TLS Feature Extension (optional)
> 
> Subscriber Certificates MAY contain the TLS Feature Extension advertising
> that the status_request feature of OCSP stapling is available and supported
> by the subscriber.  If present, this field MUST NOT be marked critical. 
> See http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02 


What is the actual problem the TLS extension on this draft solves?
A client doesn't need an extension to drop the connection if an OCSP
reply cannot be obtained. Moreover there are very few cases where a
server would like to force the client to disconnect if such a reply is
not available since the CA's OCSP server is typically outside its
control, and which server administrator would like his site to go down
every time the CA's server goes down.

For the latter if the server is really concerned about the client
getting the OCSP replies, he can send them in-band anyway using the
status request extension (and if the server doesn't support this
extension - as mentioned in the draft - why would it support the new one?)

regards,
Nikos