Re: [TLS] OCSP must staple

Tom Ritter <tom@ritter.vg> Sun, 08 June 2014 05:11 UTC

Return-Path: <tom@ritter.vg>
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 4A5C21A02D3 for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 22:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 Ziu6NBnLSguX for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 22:11:15 -0700 (PDT)
Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE551A02D4 for <tls@ietf.org>; Sat, 7 Jun 2014 22:11:15 -0700 (PDT)
Received: by mail-ve0-f180.google.com with SMTP id jw12so2295063veb.39 for <tls@ietf.org>; Sat, 07 Jun 2014 22:11:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/Nye1xXJVwYTiUODSGHncv36/SdM3tKIucqy7fYK8ZA=; b=Y/NZ58qwr124HumBs8B9gNE62I58WGom5bDrvwihUIIPFLYifYBqipkuMVkx9RQY2/ KAk/HlY97mvmlBqYH+i7gISrq31LNXdSIkPbUBOGcIUUxqt1+vzHo3A0IcjonroT13HL pFhJY1WrsFssY7Gdnd7gNS7B81tXjajmkc++g=
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:from:date :message-id:subject:to:cc:content-type; bh=/Nye1xXJVwYTiUODSGHncv36/SdM3tKIucqy7fYK8ZA=; b=LauiyvzhmckNg+CBFFbIzRi6BR21hRRpeXLT4YYdPUUXI3M2RKZ88dMLxSXIgXHtDW wGDj8+7qEPqirOGAwtwcWD4YHLtlviSLOw7ioNwFuvXRDXoe3+dU65BVAa9IV3/q8CHA /Fc7fQ2f4cx0pWg3PmiyQhPBeonV0KpeAWCMSIwnQ0vX3fr96embV9nvuJY3f/dqR1zR TUbLTAEFlnJM33x6OqGIGkPPNZEIFa0cdxAtavC9XTCponuxImiL722TGjpYQPAC+wPF ipH0OVlE58FrUiOagQ34fGN7Lk7H2uHmhwB3UTGcZ/mwKlgWXLr1/PFaost4DYRaHXSV omFA==
X-Gm-Message-State: ALoCoQmo2TCJxWQ31a7l8j/uzysXNkLanDsSN6fSUpHKvuZePFTExOCS5Hhgu6i5ZKqd2cOGNUDR
X-Received: by 10.220.69.72 with SMTP id y8mr17185648vci.21.1402204267467; Sat, 07 Jun 2014 22:11:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.106.39 with HTTP; Sat, 7 Jun 2014 22:10:47 -0700 (PDT)
In-Reply-To: <C877733F-EBCC-4D88-8B99-271914A517B4@gmail.com>
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>
From: Tom Ritter <tom@ritter.vg>
Date: Sun, 8 Jun 2014 01:10:47 -0400
Message-ID: <CA+cU71nPXxpk05F+5bthRDXyJKVQwHQGSmT0B3qkCg875B69AQ@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a925043ed1c04fb4c1f51
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5jBFEWMEhwg0aK9Xmlr3jKLtw6k
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: Sun, 08 Jun 2014 05:11:17 -0000

On 8 June 2014 00:59, Yoav Nir <ynir.ietf@gmail.com> wrote:

> dictate to whom?  Isn't the presence of this extension a mandate on the
> server operators themselves?
>

Well, yes, but in the same way that HSTS is a mandate on a server operator
to make their site available over HTTPS.  I think the mandate is more
accurately terms as for the client.  If a staple is not provided, you
should reject the certificate as invalid.


> And enforced how?  Suppose a server sends the client a certificate with
> the extension, and does not staple an OCSP response, are clients going to
> cut the connection or are they going to try the OCSP server. And if they
> try the OCSP server, is ti going to reject them?
>

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.


> I'm trying to get my head around how this extension is going to be
> deployed.
>

I see it as a server opting in to strict revocation checking for a
certificate.  (Later on, for the host itself, but for now, just the
certificate.)

-tom