Re: [TLS] OCSP must staple

Brian Smith <brian@briansmith.org> Thu, 12 June 2014 18:21 UTC

Return-Path: <brian@briansmith.org>
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 E9EEC1B27EF for <tls@ietfa.amsl.com>; Thu, 12 Jun 2014 11:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VB0H6c5D_L2e for <tls@ietfa.amsl.com>; Thu, 12 Jun 2014 11:21:54 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420761B27BB for <tls@ietf.org>; Thu, 12 Jun 2014 11:21:54 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id j7so918528qaq.38 for <tls@ietf.org>; Thu, 12 Jun 2014 11:21:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O8pqrxwdn9uR/kzU+niNwA8FUF3otJvsVC3/wkEMYbw=; b=XTiVzSI2B7G09Vm7vrzLq9Ze5PqFB7eu1YUoIOCksEAnT4oM3Tv2mspizwOkfOaqzm Rb1JfNyln+fluIHATPo3sPKoqVDlI+MNB/t+nX6yvfRAUiGPz1rL1594e716u5b+YF6m xeCvSiLNACkHIc4eXgW9kwplu5SEblk2oaFnsNaA052J4XWDPNy6JCeYiIsJgHHr+0y8 Jyi/1/bL4bJEpF5HSbS/wn+eVsn8XbYLUenqa2G6ZnVCbHMVvIYAaEYxArVH4uzsZu/2 7OiA4qiuYRsYB6tcUNHawGNLXzO3kuGGrMJRG5mADxPfsyHm7DISoJxDDPKzNCGsGrYl 3pVQ==
X-Gm-Message-State: ALoCoQkGbr4gV9Uwr0GR6qVXDvai69HuZAVxBiaYoy2FIO3jfkZ6nC86ure0tb9gKoXPXVLf+kVv
MIME-Version: 1.0
X-Received: by 10.224.36.141 with SMTP id t13mr59632384qad.75.1402597313448; Thu, 12 Jun 2014 11:21:53 -0700 (PDT)
Received: by 10.224.212.3 with HTTP; Thu, 12 Jun 2014 11:21:53 -0700 (PDT)
In-Reply-To: <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@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>
Date: Thu, 12 Jun 2014 11:21:53 -0700
Message-ID: <CAFewVt7YbTz9_NwBt_FDLpPog5sUGsE5GMYOgaZaJXCDkfOL5w@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=089e0149d0e4a1a3d004fba7a22a
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dvx1IaRmrMMIoO-VD0D6g_e8b9g
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: Thu, 12 Jun 2014 18:21:57 -0000

On Thu, Jun 12, 2014 at 2:02 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> Regarding TLS proxies, I can give my perspective, as I work for one
> vendor.
>
> <hat type=“vendor” status=“on”>
> Our fake certificates contain the DNs and alternate names from the
> original certificate. We don’t copy over any extensions that we don’t
> understand. The same is also true of TLS - we don’t copy extensions we
> don’t know. That is what allows our proxy to gracefully downgrade HTTP/2 or
> SPDY clients and gateways to HTTP/1.
> As for dates, these *are* copied from the original certificate, the reason
> is that this makes the client behavior similar to whatever it is with the
> original certificate. We did consider making the certificates short-lived,
> but decided against it.
> </hat>
>
> So your proposed heuristic for detecting fake certificates will work with
> some proxies, but not all. Adam’s suggestion should work better, but best
> is if the fake certificate doesn’t promise things the proxy CA doesn’t
> understand.
>

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.

Cheers,
Brian