Re: [TLS] OCSP must staple

Yoav Nir <ynir.ietf@gmail.com> Fri, 13 June 2014 04:52 UTC

Return-Path: <ynir.ietf@gmail.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 BCC4D1B28A8 for <tls@ietfa.amsl.com>; Thu, 12 Jun 2014 21:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ToM7VhRUKl3Y for <tls@ietfa.amsl.com>; Thu, 12 Jun 2014 21:52:53 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638821B28AB for <tls@ietf.org>; Thu, 12 Jun 2014 21:52:53 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id cc10so200284wib.6 for <tls@ietf.org>; Thu, 12 Jun 2014 21:52:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=CTyh2O9e0CBmg4PWSWm1fUl+XQrXxPulm7+OkmrpgKw=; b=mrmBYSzp1taBHX40u2tjSucR48R3/Z1T57R6JDWo4CdgO7ys/acsY1JCr/VLMmCG+P TZvSYTaBwbO2hASKjIE+wVvCO5I+yNnpRN6NNym6eckVN3EuUm2ZnbyE6iOq+Tjma8C3 gS73Ue8IxpIMkcemroLtG5f+gxBfNL8bbwZBGnML7fPGb3sr6/nKzpZu4BrebcBNLm8Z 3Wv34LCoNKyIIN9+/80xSPhh5Elox1V0CKlyUYnfRUhxfVRJAubjllmLzlfs7mI1OZJY 7Cfb1kYxMhvECcUSbtDGI8oH2+cj3uGQOLN29HY4fgQOXoOQxcEe6mItzxOIEtY+LN6D B57A==
X-Received: by 10.194.6.166 with SMTP id c6mr511912wja.64.1402635170778; Thu, 12 Jun 2014 21:52:50 -0700 (PDT)
Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id l41sm9245272eew.8.2014.06.12.21.52.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 21:52:49 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B2AD33A8-C601-4DD6-952C-DFC33F5496A1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAFewVt7naEVVVFsKLFK_pDSjw=N4K+ghNPEZDP41kvaL6OVbcg@mail.gmail.com>
Date: Fri, 13 Jun 2014 07:52:47 +0300
Message-Id: <6407EEB5-E138-4B50-83D1-D68E1DC8E5EE@gmail.com>
References: <20140528184735.GA20602@roeckx.be> <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> <5390B1D6.5010105@nthpermutation.com> <CAFewVt6Pr8yjV8EbYLp1HQJfYMgq2LJMt4uQqZWKChR6p12Wtg@mail.gmail.com> <5390CA45.1050504@nthpermutation.com> <CAFewVt6qfqHW2Df=aXhmo-Fucvn_PUzM8NVQV-aYiH9Ttfhjmw@mail.gmail.com> <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> <CAFewVt7YbTz9_NwBt_FDLpPog5sUGsE5GMYOgaZaJXCDkfOL5w@mail.gmail.com> <49B8F9EA-40C6-442D-9E7E-2B09E42CDCC1@gmail.com> <CAFewVt7naEVVVFsKLFK_pDSjw=N4K+ghNPEZDP41kvaL6OVbcg@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YhlXqEGvm-6gRfxkOFXR7SObRbI
Cc: "<tls@ietf.org>" <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: Fri, 13 Jun 2014 04:52:55 -0000

On Jun 13, 2014, at 2:44 AM, Brian Smith <brian@briansmith.org> wrote:

> On Thu, Jun 12, 2014 at 2:45 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
> On Jun 12, 2014, at 9:21 PM, Brian Smith <brian@briansmith.org> wrote:
>> Thanks for sharing that information. Does your product copy all the certificate policies from the original certificate into the forged certificate? If your product doesn't copy certificate policies it doesn't understand, then there wouldn't be an interop issue with your product and the use of certificate policies for Must-Staple, even if your product doesn't generate short-lived certificates.
> 
> IIRC we don’t copy certificate policies at all, but I could be wrong. 
> 
>  It would be great to get a more definitive confirmation of that, not just from you, but from other vendors of similar products.

The weekend for us is Friday+Saturday, so I’ll only be able to check this only on Sunday.

> The thing is, a browser like Mozilla has to work with many different interceptors around, so there might be one that does copy all extensions, but doesn’t make short-lived certificates.
> 
> I agree there probably is one that is especially problematic like that. But, it seems like we should actually find such a problematic one deployed before we start limiting the usefulness of the feature to accommodate it.

A TLS proxy acts as both CA and server for the client. If it emits a certificate that says it must staple and then doesn’t staple, then the proxy is the one with the bug, the “last one who changed” doctrine notwithstanding.

OCSP stapling has privacy benefits. I don’t think it’s warranted to disable that feature because of somebody else’s implementation bug. 

Yoav