OCSP exception contingent on must-staple (was Re: SHA1 certs issued this year chaining to included roots)

[Richard Barnes]

Changing the subject line as this is branching a bit...

On Wed, Jan 20, 2016 at 8:24 AM, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 19/01/16 21:13, Charles Reiss wrote:
>
>> On 01/19/16 11:49, Jakob Bohm wrote:
>>
> <snip>
>
>> If there is no OCSP, it obviously cannot be stapled.
>>>
>>
>> The CA/Browser forum BRs contemplate OCSP stapling without an OCSP
>> responder
>> being listed in the certificate in section 7.1.2.2.c ("The HTTP URL of
>> the
>> Issuing CA’s OCSP responder MAY be omitted, provided that the Subscriber
>> “staples” the OCSP response for the Certificate in its TLS handshakes
>> [RFC4366].") I assume the idea is that the OCSP responder URL would be
>> manually
>> configured in the server and that this would make the certificate
>> slightly smaller.
>>
>
> IIRC, the original motivation for this text was to make it possible to
> suppress OCSP requests directly from TLS clients (that don't support OCSP
> Stapling). In particular, there was a concern that some OCSP responders
> might not be able to cope with the OCSP traffic generated by certs used by
> sites with extremely high numbers of users.
>
> At the time, Firefox didn't support OCSP Stapling, and it was much less
> common for CAs to use CDNs for their OCSP responders. (Indeed, some CAs
> didn't even support OCSP back then).
>

This sentence has always bothered me, though, because in order to make
sense, you would have to have the CA verify that the OCSP response is
stapled, and there's not any requirement to do that. ISTM that omitting
the OCSP URL only really makes sense if there's a TLS Feature extension
requiring stapling (i.e., must-staple).

"""
The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted, provided
that the Certificate contains a TLS Feature extension including the value
status_request(5). This extension requires that the Subscriber “staples”
the OCSP response for the Certificate in its TLS handshakes [RFC4366]."
"""

If this is non-controversial, maybe this is something to add to Bowen's
ballot that's being discussed on another thread?

--Richard



>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Rob Stradling]

On 20/01/16 14:35, Richard Barnes wrote:
> Changing the subject line as this is branching a bit...

<snip>

>> IIRC, the original motivation for this text was to make it possible to
>> suppress OCSP requests directly from TLS clients (that don't support OCSP
>> Stapling). In particular, there was a concern that some OCSP responders
>> might not be able to cope with the OCSP traffic generated by certs used by
>> sites with extremely high numbers of users.
>>
>> At the time, Firefox didn't support OCSP Stapling, and it was much less
>> common for CAs to use CDNs for their OCSP responders. (Indeed, some CAs
>> didn't even support OCSP back then).
>>
>
> This sentence has always bothered me, though, because in order to make
> sense, you would have to have the CA verify that the OCSP response is
> stapled, and there's not any requirement to do that. ISTM that omitting
> the OCSP URL only really makes sense if there's a TLS Feature extension
> requiring stapling (i.e., must-staple).

Now that Must-Staple exists, then yes, definitely.

> """
> The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted, provided
> that the Certificate contains a TLS Feature extension including the value
> status_request(5). This extension requires that the Subscriber “staples”
> the OCSP response for the Certificate in its TLS handshakes [RFC4366]."
> """
>
> If this is non-controversial, maybe this is something to add to Bowen's
> ballot that's being discussed on another thread?

+1

[Jakob Bohm]

Let me once again reiterate that non-stapled OCSP is inferior (except
perhaps in bandwidth) to properly implemented CRLs.

The point of this is that insisting on OCSP as a mandatory checking
protocol is actually harmful and any requirements must be worded such
that it doesn't become the only available protocol.

With CRLs:

The private key that signs (non-)revocation information need never be
accessible from any online machine, not even indirectly.

The browser request to download the latest (delta) CRL does not leak
information about websites or mail-addresses being accessed.

CRL update downloads can be preloaded over idle bandwidth whenever the
old ones are about to expire.

There is the bandwidth overhead of downloading the CRL entries for
certificates the user is never going to see/check. The size of this
overhead depends heavily on the degree of delta-CRL support available.


With online (non-stapled) OCSP:

At least one private key authorized to sign (non-)revocation
information needs to be accessible from the online OCSP responder
(because not all OCSP queries can be answered with pre-signed
responses).

A simple wiretap on the (never encrypted) internet connection near the
OCSP responder will provide the spy with a near-complete realtime list
of who browses what https websites and exchanges encrypted e-mail with
which users, without having to set up wiretaps on thousands of
worldwide links between users and websites.

Bandwidth and time delays to download OCSP responses has to occur at
the time of the request and cannot be easily preloaded.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded