Re: [TLS] OCSP must staple

"Jeremy Rowley" <jeremy.rowley@digicert.com> Mon, 09 June 2014 19:50 UTC

Return-Path: <jeremy.rowley@digicert.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A831A02E3 for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 12:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.953
X-Spam-Level:
X-Spam-Status: No, score=-4.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55uwctNH7EhJ for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 12:50:02 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id AA9871A02E2 for <tls@ietf.org>; Mon, 9 Jun 2014 12:50:02 -0700 (PDT)
Received: from JROWLEYL2 (unknown [67.137.52.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 3C6097FA217; Mon, 9 Jun 2014 13:50:02 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1402343402; bh=FjIeDvpgbwomhRbj1ueE3H33haJ7LmW9I8OuquadOLM=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=fU2cenkwBQQY9Rn2BiAzjJn8ayzcgBb8Cp2pRxT7Bju7YWYZu95iUl6t6UseWGi4d gLV9zEd+ZkLLPx+rFMJNLv54vVdwDT9+2H3ZI0lK80yHODV4eYtjzUdFM8qhyODPnq z4aYAA5seTZajHtoYUQBMPxR3q5TD5Q3pcKfQgZQ=
From: "Jeremy Rowley" <jeremy.rowley@digicert.com>
To: <ryan-ietftls@sleevi.com>, "'Tom Ritter'" <tom@ritter.vg>
References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <CAMm+LwgTnva9jJgVfkaOZ1qP0Rk3w-mFfepnubosgtrCEARv=g@mail.gmail.com> <539069CC.5010304@cs.tcd.ie> <CAFewVt4p4rJ738Yo=XQm6T_jyvG3TnJsSQ5HDZDrqAkyNDa7tg@mail.gmail.com> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <C877733F-EBCC-4D88-8B99-271914A517B4@gmail.com> <CA+cU71nPXxpk05F+5bthRDXyJKVQwHQGSmT0B3qkCg875B69AQ@mail.gmail.com> <455964081e9c154c6a68781b35d87ba9.squirrel@webmail.dreamhost.com>
In-Reply-To: <455964081e9c154c6a68781b35d87ba9.squirrel@webmail.dreamhost.com>
Date: Mon, 9 Jun 2014 13:50:01 -0600
Message-ID: <031701cf841c$00cab8b0$02602a10$@digicert.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJxv6HtmB9uk8Yt5wEeFHdRD1knoQEt2WjqAP+sMUYCHog9/QJH2PNTApX9AA0COSwKkwNalKqnAp4CcngB5F3w/QJ8kG4OAaygmc0CNMpOtAIE/YvOAdczQaACTQHEx5kmeskw
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Lth-obF2nzWf-52m2TheYd9W75g
Cc: tls@ietf.org
Subject: Re: [TLS] OCSP must staple
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Jun 2014 19:50:05 -0000

I agree with Ryan.  In my view, if must staple is present, the server
operator is requiring a stapled response and specially requesting the client
not to communicate with the CA.  In that case, the connection should fail
instead of using a fallback. The RFC language already reflects this:

If the TLS status_request feature is specified in the TLS Feature
   extension and a TLS client specifies the status_request feature in
   the Client Hello, a server MUST return a valid OCSP token for the
   specified server's End Entity certificate in the response.

Also in Section 2:
The inclusion of a TLS feature extension advertising the
   status_request feature in the server end entity certificate permits a
   client to fail immediately if the certificate status information is
   not provided by the server.  

Jeremy

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ryan Sleevi
Sent: Sunday, June 8, 2014 10:15 PM
To: Tom Ritter
Cc: tls@ietf.org
Subject: Re: [TLS] OCSP must staple

On Sat, June 7, 2014 10:10 pm, Tom Ritter wrote:

>  While it looks some of the semantics of 'Must Staple', I think either  
> behavior could be acceptable for a client.  Either closing the 
> connection  without attempting to contact a OCSP server, or switching to a
'Hard Fail'
>  OCSP lookup.
>
>  I can imagine some servers deciding that they would want clients to 
> fail  if  they didn't send a staple, rather than leak the OCSP lookup 
> to the CA.  I  could imagine other servers wanting to hedge their bets 
> and have the  client  make an attempt before giving up.
>
>  I don't understand what you mean by the OCSP server rejcting them.

It's not really "must staple" if clients fall back to doing lookups, is it?
It's more like "should consider staple" (RFC 6919)

I would expect conforming clients to fail if must-staple is present but not
stapled. This includes ignoring OCSP cached responses, and prevents online
lookups.

This interpretation is key among the reasons why Chrom{e/ium} has not
(yet) begun experimenting with must staple, since the APIs used don't offer
as much flexibility. However, that interpretation is exactly what ensures
interoperability - these sorts of "soft fallbacks" cause a number of issues,
as everyone in the TLS WG can attest to elsewhere (eg: TLS version rollback,
AIA chasing, etc)

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls