Subject: Re: [TLS] OCSP must staple

From: Sean Turner <[email-masked]>
Date: Tue, 3 Jun 2014 20:39:54 -0400

I believe that draft has been abandoned in favor of:

http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/

Personally, I don’t think this draft is applicable to the TLS WG and would be better suited as an AD sponsored draft.  I know PHB approached me about sponsoring it but I think we both got busy before the end of my term.  I’ve not doubt PHB will at some point approach Stephen/Kathleen about sponsoring it.  If you’re interested in supporting it, sending them a message might help ([email-masked]).

spt

On May 28, 2014, at 15:00, Jeremy Rowley <[email-masked]> wrote:

> We do.  I believe PHB was waiting for an OID assigned by IANA for must
> staple.   I'm not sure the request was ever submitted, but I'll follow up
> and make sure this moves forward.
> 
> Jeremy
> 
> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Kurt Roeckx
> Sent: Wednesday, May 28, 2014 12:48 PM
> To: [email-masked]
> Subject: [TLS] OCSP must staple
> 
> Hi,
> 
> It seems there is a draft to have OCSP must staple
> (draft-hallambaker-muststaple-00).  Does anybody know what the status of
> that is?  I've tried to contact the author but didn't get any reply.
> 
> Is this something we want adopt?
> 
> 
> Kurt
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jun 2014 11:40:27 +0100

Hiya,

On 04/06/14 01:39, Sean Turner wrote:
> Personally, I don’t think this draft is applicable to the TLS WG and
> would be better suited as an AD sponsored draft.  I know PHB
> approached me about sponsoring it but I think we both got busy before
> the end of my term.  I’ve not doubt PHB will at some point approach
> Stephen/Kathleen about sponsoring it.  If you’re interested in
> supporting it, sending them a message might help
> ([email-masked]).

I did discuss AD sponsoring this with Phill and am fine with
that plan since there is (I believe) support for implementing
it in some browsers.

So Phill - please tell me when you think this is ready and
if possible recruit a document shepherd if you've not already.

S.

>> We do.  I believe PHB was waiting for an OID assigned by IANA for
>> must staple.   I'm not sure the request was ever submitted, but
>> I'll follow up and make sure this moves forward.
>> 
>> Jeremy
>> 
>> -----Original Message----- From: TLS [mailto:[email-masked]]
>> On Behalf Of Kurt Roeckx Sent: Wednesday, May 28, 2014 12:48 PM To:
>> [email-masked] Subject: [TLS] OCSP must staple
>> 
>> Hi,
>> 
>> (draft-hallambaker-muststaple-00).  Does anybody know what the
>> status of that is?  I've tried to contact the author but didn't get
>> any reply.
>> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Jun 2014 13:59:56 +0100

Hiya,

On 05/06/14 13:40, Phillip Hallam-Baker wrote:
> By which I simply mean, lets make get people to actually read that
> particular draft rather than start a cabal. So if we give folks a week
> and then we can go forward with the document shepherd?

Sure works for me. Can you try recruit a shepherd?

I'll do an AD review in any case before I start IETF LC and will
post a copy of that here. If other folks have comments I guess
send those here or to PHB and me. I'd be happy to get a couple
of mails saying "read it, its ready" after Phill's done his
tweaks as well btw.

Cheers,
S.

---

From: Brian Smith <[email-masked]>
Date: Thu, 5 Jun 2014 10:05:22 -0700

> of mails saying "read it, its ready" after Phill's done his

I read the document. I disagree with the documented semantics of the
extension when it appears in a CA certificate.

The specification says that when the extension appears in a CA certificate,
then the extension with the same values must also appear in all
certificates under that CA certificate. And, it says that a client may
ignore the extension in CA certificates. It would be safer if clients were
required to enforce the Must-Staple restriction if the extension appears in
any CA certificate in the chain. That way, the mechanism would work even
against an attacker that can issue themselves an end-entity certificate
that does not have the "must-staple" feature.

If this change were made, then the encoding of certificates as sent on the
wire would also become more efficient because fewer copies of the extension
would be needed: For example, in a chain EE <- Int1 <- Int2 <- Int3, where
Int3 contains the extension, the savings would be 3x the size of the
extension. Granted, the extension isn't large, but we should avoid such
waste since the size of certificates does have a significant impact on TLS
handshake performance.

IIRC, one previous version of the draft specified a mechanism for a CA
certificate to indicate that the OCSP response for the CA certificate must
also be stapled, using the OCSP multi-stapling mechanism. I think this is a
useful feature and we should bring this feature back. Otherwise, we'll have
to specify a new version of Must-Staple to support this later.

A more minor concern: It seems strange to have an X.509 extension, which is
identified by an OID, which is simply a list of unrelated features
identified by OID. In particular, why not just have a "Must-Staple" X.509
extension (or two: Must-Staple-End-Entity and Must-Staple-All) that is
(are) empty, and avoid the need for the "feature" wrapper extension? The
wrapper made more sense in earlier drafts because there was more than one
feature specified. Now, it doesn't seem to make sense. Removing the wrapper
would make the mechanism simpler and I think we should remove the wrapper.

Let's say a website's certificate's private key has been compromised and
that certificate was NOT Must-Staple. The website has no truly effective
mechanism to revoke that certificate, at least as far as browsers are
concerned. We saw how this played out (is playing out) with the Heartbleed
stuff. I think in the many years before Must-Staple could become
ubiquitous, we'll need another mechanism to indicate that all certificates
for a given hostname must be Must-Staple, whether they contain the
Must-Staple feature in the X.509 certificate or not. I don't know that that
has to be addressed in *this* draft or in a draft of a different feature,
but it seems like in the near term we should also have a mechanism that
applies to certificates that do not contain the feature.

Cheers,
Brian

---

From: Tom Ritter <[email-masked]>
Date: Thu, 5 Jun 2014 13:14:18 -0400

On 5 June 2014 13:05, Brian Smith <[email-masked]> wrote:

> I think in the many years before Must-Staple could become ubiquitous,
> we'll need another mechanism to indicate that all certificates for a given
> hostname must be Must-Staple, whether they contain the Must-Staple feature
> in the X.509 certificate or not. I don't know that that has to be addressed
> in *this* draft or in a draft of a different feature, but it seems like in
> the near term we should also have a mechanism that applies to certificates
> that do not contain the feature.
>

I believe it is many people's intention (at least it is mine) to include it
as a directive in HSTS.  There'a an argument to make it a separate header,
like PKP.  "What if I want my site not to require SSL, but if it does, to
use these certs and that they should be stapled."

-tom

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jun 2014 17:32:23 +0000

> extension when it appears in a CA certificate.

[ Apologies if my understanding of how the revocation process works
in practice is a bit stale, perhaps things are better now than the
last time I looked. ]

This extension introduces a requirement to implement OCSP stapling
predicated on the assumption, that we have usable revocation
mechanisms, and that all that remains is for clients to learn in
a reasonably timely manner that a certificate has been revoked.

It also assumes that servers are generally deployed in environments
where periodically obtaining OCSP responses from the server's CA
for stapling is practical.

There at this time to my knowledge no standard companion protocol
for OCSP that allows the holder of a key pair (when the private
key is not lost) to sign a request to the CA to revoke the
certificate.  Instead, it is my impression, that we have "challenge
phrases" that are often not set or lost, and CA-specific interfaces
to activate revocation.

If, this is indeed the case, then I claim that mandatory OCSP
stapling is putting the cart before the horse.  Only a tiny fraction
of certificates can be effectively revoked.  I would like to see
CAs stop publishing CRLs entirely (solving the scaling issue for
mass revocations as with Heartbleed), implement only OCSP, and
provide a standard zero-cost revocation protocol when the private
key is available (or when a miracle happens and the "challenge"
password is actually known).

Once revocation is a scalable working process, then we can benefit
from insisting on OCSP stapling, provided we figure out what to do
with servers that don't have any way to reach out and refresh OCSP
responses for stapling, nor support interface for an agent to
obtain the response on the server's behalf and push it into the
server's configuration.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 5 Jun 2014 13:36:37 -0400

EV certs, which are important to many businesses, basically require browsers to do OCSP.

An offline protocol -- "yes, this is Larry, please revoke and re-issue all Google certificates" -- suffices for those large organizations.

Yes this leaves the smaller players out.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Michael StJohns <[email-masked]>
Date: Thu, 05 Jun 2014 14:07:18 -0400

Hi -

The note by Brian Smith made me take a second look at 
http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/. From the 
list chatter, I thought it was pretty much a standard CA extension.  I 
didn't realize that PHB had defined it as a transitive (i.e. if the CA 
has it, then it applies all the way down the chain) extension, rather 
than just a simple one-off application.

Given the above, I would reject the document and suggest instead that 
this use the CertificatePolicies extension.

Two ways of doing this:

First:

1) Define a policy OID for each TLS feature - the set is pretty small 
right now and I don't see it growing all that much.  This is probably 
the right approach and doesn't require anything more than a description 
of the OID and the related policy processing.

or Second

1) Define a policy OID for TLS Features
2) Define a PolicyQualifier OID for a FeatureIds qualifier
3) Define "FeatureIds ::= SEQUENCE of TlsFeatures"
4) Define "TlsFeatures ::= INTEGER { feature1 (1), feature2(2), ...}

This is more flexible, but seems to violate the spirit of RFC5280, 
section 4.2.1.4 - the "RECOMMENDS" items.

Doing it one of the above ways doesn't require modification to the cert 
path building logic (which isn't fully specified in the draft and should 
be).  The first also - mostly - doesn't require changes to code that 
build certificates which means it could enter production on the cert 
side much quicker.

Mike

---

From: Brian Smith <[email-masked]>
Date: Thu, 5 Jun 2014 12:12:01 -0700

On Thu, Jun 5, 2014 at 11:07 AM, Michael StJohns <[email-masked]>
wrote:

> I didn't realize that PHB had defined it as a transitive (i.e. if the CA
> has it, then it applies all the way down the chain) extension, rather than
> just a simple one-off application.
>

I don't think it actually is transitive. That is why I was asking it to be
changed to be transitive. I guess either way the draft should be clarified
regarding this.

Given the above, I would reject the document and suggest instead that this
> use the CertificatePolicies extension.
>

<snip>

> This is more flexible, but seems to violate the spirit of RFC5280, section
> 4.2.1.4 - the "RECOMMENDS" items.
>

Right, we should avoid going against RFC 5280's  recommendation here, so I
don't think this is a reasonable option.

> be).  The first also - mostly - doesn't require changes to code that build
> certificates which means it could enter production on the cert side much
> quicker.
>

Is it really significantly easier for CAs to add new certificate policies
compared to adding new certificate extensions? I could see how that could
be the case, but I think it would be good to hear from CAs about this.

I think one consideration is whether somebody that is operating an
externally-operated sub-CA using closed-source, slow-release-cycle software
(e.g. Microsoft's CA software) could implement the policy-based approach
without waiting for any patch/update from their vendor. If that is the
case, that would be a significant benefit of your (policy-OID-per-feature)
policy-based approach.

Cheers,
Brian

---

From: Michael StJohns <[email-masked]>
Date: Thu, 05 Jun 2014 15:51:33 -0400

On 6/5/2014 3:12 PM, Brian Smith wrote:
> Is it really significantly easier for CAs to add new certificate 
> policies compared to adding new certificate extensions? I could see 
> how that could be the case, but I think it would be good to hear from 
> CAs about this.

Mostly the "put a policy object in the ca certificate" reduces to 
"configure the text string of the OIDs you want to include". 
https://www.openssl.org/docs/apps/x509v3_config.html#Certificate_Policies_ 
for example.

The certificate policy extension is pretty well formed, which means that 
its pretty easy to specify in configuration language (e.g. xml, 
label=value) what you want to be included rather than having to go back 
and add new ASN1 encode/decode/translate to and from string logic.  
Things like Dogtag and EJBCA support it via a gui.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Jun 2014 08:40:22 -0400

> if possible recruit a document shepherd if you've not already.

With that answer in hand, I suggest that we first do an internal last
call on the draft currently on the table to see that everyone is
happy.

I do need to write an IANA piece which I will do today. At the time I
wrote it the assignment was not an IANA one.

I am pretty sure the document is ready otherwise. I took out the bit
that allowed a minimum version of TLS to be specified after
discovering that is not practical from one of the browser providers.

-- 
Website: http://hallambaker.com/

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 7 Jun 2014 18:49:45 +0200

On Thu, Jun 05, 2014 at 05:32:23PM +0000, Viktor Dukhovni wrote:
> I would like to see
> mass revocations as with Heartbleed)

CRLs are useful.  And I wish all CAs published them.  But I do not
recommend them to check that the certificate is revoked or not at
the time of a connection.

> implement only OCSP, and

I do not understand what you're really trying to say here.

I think we all agree that we want everybody to do OCSP.  I think
we also want everybody to do OCSP stapling by default when
possible.  But that doesn't mean we want everybody be forced to
do OCSP stapling.

I fail to see how this relates to revocation process.  If there is
a problem in the revocation process having CRL, OCSP, OCSP
stapling, or OCSP must staple will all have the same effect.

I am curious about your use case for servers that can't refresh
the OCSP response.  And is this any different in the case of CRLs?
Or are you just happy to ignore the non-existence of the CRLs?

Kurt

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Jun 2014 17:06:19 +0000

> possible.  But that doesn't mean we want everybody be forced to

If CAs start issuing "must staple" certificates, isn't that "forced"?

> stapling, or OCSP must staple will all have the same effect.

I don't see much value in (especially) CRLs or (even) OCSP stapling
without a scalable effective revocation process.

> Or are you just happy to ignore the non-existence of the CRLs?

CRLs don't scale, client initiated OCSP to CA leaks too much
sensitive data to the CA, and and fails open.  OCSP stapling is
the only revocation mechanism left standing, but some servers
will have difficulty supporting it.  Not all servers are HTTP
servers, and servers may lack "HTTP client" capabilities to
connect to the CA's OCSP responder.  Servers may be on networks
where they have to traverse various firewalls, proxies, ...
to get to the OCSP responder, the burden may be too high.

CRL's are a client-side issue I am prepared to "ignore" (would like
to see disappear).

-- 
	Viktor.

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 7 Jun 2014 19:36:20 +0200

> If CAs start issuing "must staple" certificates, isn't that "forced"?

This will only add the posibility to do so.  And CAs may wish to
enforce this on some (high traffic) sites.  But it's not because
you make this posibile that they will do this for all
certificates.

> without a scalable effective revocation process.

So are you saying that if a CA wants to use "must staple" it must
also do something about it's revocation process?

I think that if you think there is something wrong with the
revocation process you should try to address that problem
independant of how we check the revocation status.

> will have difficulty supporting it.

What is the difficulty in supporting it?

> Not all servers are HTTP
> connect to the CA's OCSP responder.

If it can already to TLS, I would think that being an HTTP client
to get an OCSP response can't be that hard.  An HTTP server isn't
special in being able to act as HTTP client.

> Servers may be on networks

If it's too high for the server, it's most likely to high
for the clients to and you should consider using an internal
CA instead.

Kurt

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 7 Jun 2014 14:13:24 -0400

> If CAs start issuing "must staple" certificates, isn't that "forced"?

In theory, but not in reality.  What is the enforcement mechanism? Trust is, ultimately, a relying party issue.  Commerce and financial sites would like to do OCSP stapling, but they won't require it if it means their customers cannot connect.  Er, trust me on this one. :)

	/r$

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Jun 2014 18:47:37 +0000

On Sat, Jun 07, 2014 at 02:13:24PM -0400, Salz, Rich wrote:

> In theory, but not in reality.  What is the enforcement mechanism?
> Trust is, ultimately, a relying party issue.  Commerce and financial
> sites would like to do OCSP stapling, but they won't require it if
> it means their customers cannot connect.  Er, trust me on this one. :)

Well, if the server *is* OCSP stapling capable, there is little
harm in having a "must staple" certificate.  So those servers won't
object to having such a certificate.  That leaves servers that can't
OCSP staple, and I guess you're sayign CAs will continue to provide
certicates without the extension to anyone who wants it.

So this another working revocation for the select few mechanism. :-)

So be it, no harm done, but larger problem lies upstream, working
revocation for the masses.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 7 Jun 2014 16:12:35 -0400

> Well, if the server *is* OCSP stapling capable, there is little harm in having a "must staple" certificate.

Except that they are depending on the CA's OCSP responder, and trusting (worrying is a more accurate term) that the browsers will do the right thing, whatever that is.  I'll be pretty surprised if the "select few," as you put it, will want must-staple certificates. 

> but larger problem lies upstream, working revocation for the masses.

Which masses?  For what? We're going through an exercise of checking the SSL certs on the true origins of many of our customers.  You'd be sadly surprised how many of them are expired, have wrong SAN fields, unknown CA's, and so on.  And even sadder if you knew how many said "we'll deal with it later, if at all."  And yet, the web commerce still marches on.

I  think the general public is put more at risk by erroneously-issued certificates, whether by accident or malicious or "national security."  Luckily, it appears that Certificate Transparency seems likely to narrow that window of exposure down to a fairly short time.

	/r$

---

From: "Jeremy Rowley" <[email-masked]>
Date: Sat, 7 Jun 2014 22:02:38 -0600

>Except that they are depending on the CA's OCSP responder, and trusting
(worrying is a more accurate term) that the browsers will do the right
thing, whatever that is.  I'll be pretty surprised if the "select few," as
you put it, will want must-staple certificates. 

Any standard "trusts" that the implementers will do the right thing.  Not
sure that's an argument against adoption.  CA OCSP responder availability
isn't a concern with stapling, especially considering uptimes typically
exceed 99.99% (http://ocspreport.x509labs.com/). We already have people
interested in using must staple upon adoption so this shouldn't be a factor
in the adopting the draft. 

>Which masses?  For what? We're going through an exercise of checking the
SSL certs on the true origins of many of our customers.  You'd be sadly
surprised how many of them are expired, have wrong SAN fields, unknown CA's,
and so on.  And even sadder if you knew how many said "we'll deal with it
later, if at all."  And yet, the web commerce still marches on.

Non-compliance by certain CAs is really irrelevant to whether OCSP Must
Staple should be adopted as a standard. Must staple is about letting server
operators dictate whether stapling is required, not on improving CA
certificate profiles. That should be addressed in a separate RFC by those
concerned with current practices. 

>I  think the general public is put more at risk by erroneously-issued
certificates, whether by accident or malicious or "national security."
Luckily, it appears that Certificate Transparency seems likely to narrow
that window of exposure down to a fairly short time.

Again, irrelevant to whether MUST Staple is adopted. CT does not preclude
MUST Staple and vice versa.  All security is a layered approach.  This is
just one more tool available to server operators to increase their level of
security. Best of all, MUST staple doesn't necessarily require a change in
current server software. Only a change in the browser to recognize the
extension.

Jeremy

---

From: Yoav Nir <[email-masked]>
Date: Sun, 8 Jun 2014 07:59:21 +0300

On Jun 8, 2014, at 7:02 AM, Jeremy Rowley <[email-masked]> wrote:

> certificate profiles. 

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

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?

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

Yoav

---

From: Tom Ritter <[email-masked]>
Date: Sun, 8 Jun 2014 01:10:47 -0400

On 8 June 2014 00:59, Yoav Nir <[email-masked]> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 8 Jun 2014 16:03:54 +0000

> I don't understand what you mean by the OCSP server rejcting them.

Well, the server was supposed to have stapled, so the OCSP server
could in principle (knowing the server's certificate requires
stapling) refuse to provide an unstapled response.

-- 
	Viktor.

---

From: Peter Bowen <[email-masked]>
Date: Sun, 8 Jun 2014 09:13:32 -0700

> stapling) refuse to provide an unstapled response.

The server is only supposed to staple if the client supports stapling.
Clients that don't support stapling will still make OCSP requests.

---

From: Tom Ritter <[email-masked]>
Date: Sun, 8 Jun 2014 12:33:15 -0400

> stapling) refuse to provide an unstapled response.

Ah I see.  The CA could reject OCSP requests for a certificate if they were
a jerk (or the customer didn't pay).  But the server's OCSP request looks
the same as a browser client OCSP request absent any non-standard
fingerprinting.  The CA's server can't reject all OCSP requests, because
the (web) server needs to make the requests.

-tom

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 8 Jun 2014 21:51:46 -0400

> Any standard "trusts" that the implementers will do the right thing. 

I don't recall any uptime requirements in any OCSP-related specs.

> We already have people interested in using must staple upon adoption so this shouldn't be a factor in the adopting the draft.

That's interesting you have customers interested in I, and that point is as valid as mine saying I don't think our customers will be.  But I didn't say it to forestall adoption of the draft, sorry if I gave you that impression.

> Non-compliance by certain CAs is really irrelevant to whether OCSP Must Staple should be adopted as a standard.

I didn't say that, either :)  I was just describing what I saw as a bigger issue. And yes, it's completely orthogonal to OCSP; sorry if I wasn't clear.

	/r$

---

From: "Ryan Sleevi" <[email-masked]>
Date: Sun, 8 Jun 2014 21:15:10 -0700

>  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)

---

From: Kyle Hamilton <[email-masked]>
Date: Sun, 08 Jun 2014 22:44:08 -0700

> I didn't say that, either :)  I was just describing what I saw as a bigger issue. And yes, it's completely orthogonal to OCSP; sorry if I wasn't clear.

I've had people tell me that they honestly believe that they're paying
the CA for the OCSP and revocation bandwidth.  This kind of viewpoint
undermines any kind of mandate for any kind of "must staple". 
Personally, I think this view is moderately short-sighted, as it relies
on a third party to be available at all times (particularly with
Firefox's "security.OCSP.require" configuration option).  When I write
protocols I include stapling as par for the course.

On the other hand, I think that relying on a stapled response is perhaps
shortsighted, as it potentially opens a window of vulnerability.  Say
the OCSP response is valid for 7 days (the maximum time that EV cert
OCSP responses can be valid for): if the cert is revoked on day 2,
that's still 5 and change days of potential validity.  This is the kind
of vulnerability that clients can use the OCSP nonce extension to
protect themselves from, but it only works if it's used and queried from
the OCSP responder by the client itself.  Thus, the proposal to prevent
clients from checking OCSP from the source in the presence of an "OCSP
must staple" extension is harmful to user security and thus wrong-minded.

-Kyle H

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Jun 2014 05:54:14 +0000

On Sun, Jun 08, 2014 at 10:44:08PM -0700, Kyle Hamilton wrote:

> OCSP responses can be valid for)

The CA may well generate new CRLs (and associated OCSP responder
state) once every 7 days.  Otherwise the OCSP response TTL should
be shorter, we should address the "right" problem.

That said there is no "right" upper bound for revocation latency.
Whatever "acceptable" limit you set, someone will always present
an argument along the lines of:

> if the cert is revoked on day 2,

One must be willing to accept some risk, and buy certificates from a
CA whose OCSP response validity interval poses an acceptable risk.

We can debate whether 7 days for EV certs is too long or not, and
whether it should be adjusted down to 2 days or 2 hours, but the
fundamental problem remains, and is independent of "must staple".

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Jun 2014 10:12:48 +0300

> must staple" extension is harmful to user security and thus wrong-minded.

I think one of the points of “must staple” is that it allows the CA to shorten the TTL without having its OCSP responder overwhelmed with traffic from clients.

Yoav

---

From: Kyle Hamilton <[email-masked]>
Date: Mon, 09 Jun 2014 00:24:28 -0700

> be shorter, we should address the "right" problem.

My assumption is that a new OCSP response SHALL be generated when the
certificate's status changes, because it is up to the CA to provide
authoritative information about records held by the CA.

In other words, by not generating a new OCSP response when a certificate
is revoked, the CA becomes complicit to any fraud done with that
certificate until the old OCSP response expires.

And, this completely ignores OCSP capacity to request a signature over a
nonce.

> CA whose OCSP response validity interval poses an acceptable risk.

One must also be able to set the level of risk that they accept.  You're
saying that there is a legal way that this can be taken out of their
hands by the CA or by "common practice".  The specifications appear to
permit a means by which this risk can be short-circuited; however,
you're asserting that "one must be willing to accept some risk", and
thus apparently applying a "MUST NOT attempt to reduce risk beyond the
CA's normally-provided limits" requirement.

> fundamental problem remains, and is independent of "must staple".

I used EV certificates only as an example.  (I do believe that 7 days
for EV is "too long", but that's beside the point.)

I do agree that the fundamental problem remains, but the reason I don't
see that it's independent of "must staple" is  in light of your earlier
assertion that "Well, the server was supposed to have stapled, so the
OCSP server could in principle (knowing the server's certificate
requires stapling) refuse to provide an unstapled response." in
explanation of Yoaf Nir's query (paraphrased) "if the client tries the
OCSP server on a must-staple certificate, will the OCSP server reject them?"

Hypothetically speaking, that kind of back-end manipulation of "you can
only have this much assurance" would make me not want to do business
with anyone who insists on doing business with that CA; but, chances are
(particularly for CAs for larger sites) I would quite often be forced
to.  I wish we had a means to present multiple certificate chains
terminating in multiple end-entity certificates of multiple keys, all of
which signed the single key presented and evidenced by the TLS peer. 
That way, any individual CA's policy to limit one's ability to reduce
one's risk would be mitigated by the policies of other CAs that the site
might decide to hire.

But this has now gone far afield from "must staple".

-Kyle H

---

From: Geoffrey Keating <[email-masked]>
Date: 09 Jun 2014 11:16:42 -0700

> must staple" extension is harmful to user security and thus wrong-minded.

I think a CA that supports OCSP with nonces would probably not be
using 'must staple'.  However very few do so and so there are no
clients that I know of that actually require a nonce in the reply; and
the OCSP protocol doesn't distinguish between 'you sent a nonce but I
will not reply with one' and 'you did not send a nonce', so the effect
is that nonces do not practically contribute to OCSP security.

---

From: "Jeremy Rowley" <[email-masked]>
Date: Mon, 9 Jun 2014 13:50:01 -0600

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:[email-masked]] On Behalf Of Ryan Sleevi
Sent: Sunday, June 8, 2014 10:15 PM
To: Tom Ritter
Cc: [email-masked]
Subject: Re: [TLS] OCSP must staple

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

> 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.
>

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)

---

From: Brian Smith <[email-masked]>
Date: Wed, 11 Jun 2014 15:49:53 -0700

On Thu, Jun 5, 2014 at 12:51 PM, Michael StJohns <[email-masked]>
wrote:

> label=value) what you want to be included rather than having to go back and
> add new ASN1 encode/decode/translate to and from string logic.  Things like
> Dogtag and EJBCA support it via a gui

I have researched some of the pros and cons of Michael's policy-based
approach. I also implemented it in a private copy of mozilla::pkix and
Firefox. In particular, I made it so:

* When the extension is present in the end-entity certificate, that a valid
"Good" OCSP response must be provided in the TLS handshake,
* There will never be any fallback to OCSP fetching or CRLs or cache
lookups when the end-entity certificate has the must-staple policy.
However, additional certificate trust information (blacklists/CRLSet) are
still consulted.
* The modified mozilla::pkix will never build a path from an end-entity
certificate or sub-CA to a higher-level CA certificate where the
higher-level CA certificate has the Must-Staple policy but the end-entity
or lower-level sub-CA certificate doesn't have the Must-staple policy.
* My modified mozilla::pkix enforces a maximum OCSP response lifetime of 2
days + slop (1 day) = 3 days if Must-Staple is present, instead of 10 days.

The good news:
* In mozilla::pkix and Firefox, it is just as easy to implement Machael's
policy-based approach as it would be to implement the approach outlined in
the draft.
* As Michael said, most if not all CA software already supports custom
certificate policies, so there is *no* new code required on the CA side for
Machael's approach. This is a significant advantage, especially because
there are a lot of companies that have purchased sub-CA certificates that
chain to publicly-trusted CAs, which use closed-source software (e.g.
Microsoft's). Basically, with Michael's approach, everybody would be able
to use Must-Staple straight away, if they want to, without writing code.

The bad news:
* TLS intercepting proxies cause trouble. In particular, some (if not all)
versions of Microsoft Threat Management Gateway forge their fake
certificates by copying the certificate policies from the original
certificate that they are trying to impersonate. Yet, Microsoft TMG does
not support OCSP stapling or in fact any kind of OCSP. Consequently, it
will copy the Must-Staple policy into the forged certificate but it won't
staple a response. I imagine other TLS intercepting proxies will do the
same.
* It is unclear what TLS intercepting proxies do with certificate
extensions that they don't understand. I would guess that some copy those
extensions into their forged certificates and others do not.

The OK news:
* From what I've found, Microsoft TMG forges certificates that are very
short lived (24hrs). Thus, if we make an exception that short-lived
certificates (<= 48 hours) with the Must-Staple feature do not need to have
a stapled OCSP response even with Must-Staple, we can probably avoid a lot
of the issues with TLS intercepting proxies, regardless of how the
Must-Staple feature is encoded in the certificate.

Thus, for ease-of-deployment reasons, I prefer Michael's policy-based
approach + the short-lived certificate exception over the approach in the
draft that uses a new extension. Regardless of which of those two
approaches is taken, we'll need to do a lot of interop testing with various
kinds of TLS intercepting proxies.

Cheers,
Brian

---

From: Adam Langley <[email-masked]>
Date: Wed, 11 Jun 2014 16:10:26 -0700

On Wed, Jun 11, 2014 at 3:49 PM, Brian Smith <[email-masked]> wrote:
> * TLS intercepting proxies cause trouble.

In Chrome (and, I assume, Firefox) there's the concept of a
"non-public root" - i.e. a CA root that the user has installed. When
one is used on a connection we disable pinning. We could also disable
Must Staple.

Cheers

AGL

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Jun 2014 12:02:40 +0300

Hi, Brian

Interesting stuff. Also good to hear that it’s easy to implement, although mileages vary.

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.

Yoav

On Jun 12, 2014, at 1:49 AM, Brian Smith <[email-masked]> wrote:

> On Thu, Jun 5, 2014 at 12:51 PM, Michael StJohns <[email-masked]> wrote:
> Is it really significantly easier for CAs to add new certificate policies compared to adding new certificate extensions? I could see how that could be the case, but I think it would be good to hear from CAs about this.
> 
> Mostly the "put a policy object in the ca certificate" reduces to "configure the text string of the OIDs you want to include". https://www.openssl.org/docs/apps/x509v3_config.html#Certificate_Policies_ for example.
> 
> The certificate policy extension is pretty well formed, which means that its pretty easy to specify in configuration language (e.g. xml, label=value) what you want to be included rather than having to go back and add new ASN1 encode/decode/translate to and from string logic.  Things like Dogtag and EJBCA support it via a gui
> 
> I have researched some of the pros and cons of Michael's policy-based approach. I also implemented it in a private copy of mozilla::pkix and Firefox. In particular, I made it so:
> 
> * When the extension is present in the end-entity certificate, that a valid "Good" OCSP response must be provided in the TLS handshake,
> * There will never be any fallback to OCSP fetching or CRLs or cache lookups when the end-entity certificate has the must-staple policy. However, additional certificate trust information (blacklists/CRLSet) are still consulted.
> * The modified mozilla::pkix will never build a path from an end-entity certificate or sub-CA to a higher-level CA certificate where the higher-level CA certificate has the Must-Staple policy but the end-entity or lower-level sub-CA certificate doesn't have the Must-staple policy.
> * My modified mozilla::pkix enforces a maximum OCSP response lifetime of 2 days + slop (1 day) = 3 days if Must-Staple is present, instead of 10 days.
> 
> The good news:
> * In mozilla::pkix and Firefox, it is just as easy to implement Machael's policy-based approach as it would be to implement the approach outlined in the draft.
> * As Michael said, most if not all CA software already supports custom certificate policies, so there is *no* new code required on the CA side for Machael's approach. This is a significant advantage, especially because there are a lot of companies that have purchased sub-CA certificates that chain to publicly-trusted CAs, which use closed-source software (e.g. Microsoft's). Basically, with Michael's approach, everybody would be able to use Must-Staple straight away, if they want to, without writing code.
> 
> The bad news:
> * TLS intercepting proxies cause trouble. In particular, some (if not all) versions of Microsoft Threat Management Gateway forge their fake certificates by copying the certificate policies from the original certificate that they are trying to impersonate. Yet, Microsoft TMG does not support OCSP stapling or in fact any kind of OCSP. Consequently, it will copy the Must-Staple policy into the forged certificate but it won't staple a response. I imagine other TLS intercepting proxies will do the same.
> * It is unclear what TLS intercepting proxies do with certificate extensions that they don't understand. I would guess that some copy those extensions into their forged certificates and others do not.
> 
> The OK news:
> * From what I've found, Microsoft TMG forges certificates that are very short lived (24hrs). Thus, if we make an exception that short-lived certificates (<= 48 hours) with the Must-Staple feature do not need to have a stapled OCSP response even with Must-Staple, we can probably avoid a lot of the issues with TLS intercepting proxies, regardless of how the Must-Staple feature is encoded in the certificate.
> 
> Thus, for ease-of-deployment reasons, I prefer Michael's policy-based approach + the short-lived certificate exception over the approach in the draft that uses a new extension. Regardless of which of those two approaches is taken, we'll need to do a lot of interop testing with various kinds of TLS intercepting proxies.
> 
> Cheers,
> Brian
>

---

From: Brian Smith <[email-masked]>
Date: Thu, 12 Jun 2014 11:21:53 -0700

On Thu, Jun 12, 2014 at 2:02 AM, Yoav Nir <[email-masked]> wrote:

> 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

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 12 Jun 2014 20:39:38 +0200

On Thu, Jun 12, 2014 at 12:02:40PM +0300, Yoav Nir wrote:
> Hi, Brian
> 
> Interesting stuff. Also good to hear that it's easy to implement, although mileages vary.
> 
> <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.

I'm wondering if it also strips things it doesn't know but are
marked critical.

Kurt

---

From: Brian Smith <[email-masked]>
Date: Thu, 12 Jun 2014 11:43:56 -0700

> one is used on a connection we disable pinning. We could also disable

That is one approach that would address the compatibility issues. However,
I think it would be better to find an approach that doesn't limit
Must-Staple to publicly-trusted root CAs. Otherwise, it will be harder than
necessary to make the case stapling + Must-Staple is a complete replacement
for OCSP fetching.

If my suggestion of making an exception for short-lived certificates isn't
good enough to address the compatibility issue (and it probably isn't) then
we could require that the Must-Staple extension in the end-entity
certificate be ignored unless it is also present in a CA certificate in the
chain. This would work as long as TLS intercepting proxies are not forging
intermediate CA certificates by copying the contents of the original
intermediate CA certificates. The downside is that every CA that would want
to use Must-Staple would have to first issue a new Must-Staple-enabled
intermediate. It would be more work, but probably it would still be less of
a barrier to enabling Must-Staple than waiting for CA management software
to add support for a new extension.

Cheers,
Brian

---

From: Yoav Nir <[email-masked]>
Date: Fri, 13 Jun 2014 00:45:32 +0300

On Jun 12, 2014, at 9:21 PM, Brian Smith <[email-masked]> 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. 

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.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Fri, 13 Jun 2014 00:48:42 +0300

> I'm wondering if it also strips things it doesn't know but are

For the server-side half of the connection, a proxy acts as a client, or in certificate terminology, a relying party. If there’s a critical extension it doesn’t understand, it rejects the certificate, and never even gets to the stage of creating a fake certificate.

So there’s the big set of certificate extension, a proper subset of this that are the extensions that the product understands, and a proper subset of that, which are the extensions that it copies. 

Yoav

---

From: Brian Smith <[email-masked]>
Date: Thu, 12 Jun 2014 16:44:28 -0700

> 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 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.

Cheers,
Brian

---

From: Yoav Nir <[email-masked]>
Date: Fri, 13 Jun 2014 07:52:47 +0300

On Jun 13, 2014, at 2:44 AM, Brian Smith <[email-masked]> wrote:

>  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.

> 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

---

From: Rob Stradling <[email-masked]>
Date: Fri, 13 Jun 2014 11:32:34 +0100

On 12/06/14 19:21, Brian Smith wrote:
> On Thu, Jun 12, 2014 at 2:02 AM, Yoav Nir wrote:
<snip>
>     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.
>
> 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.

So far we've been discussing two options for how to encode the Must 
Staple indicator:
   - As a new Certificate Extension.
   - As a Certificate Policy.

Here's a third option...
   - Put it in the Authority Information Access extension.

RFC5280 says that the AIA extension...
   "indicates how to access information and services...(which) may
    include on-line validation services and CA policy data."

The AIA extension's id-ad-ocsp "accessMethod" specifies "how to access" 
the origin OCSP Responder directly.  Now, compare id-ad-ocsp to OCSP 
Stapling and Must Staple...
   - "information and services": identical.  For all three, what we want 
is an OCSP Response.
   - "how to access":
     id-ad-ocsp: SHOULD get the OCSP Response from the OCSP Responder.
     OCSP Stapling: SHOULD get the OCSP Response from the TLS handshake.
     Must Staple: MUST get the OCSP Response from the TLS handshake.

We could...
1. Use the existing id-ad-ocsp "accessMethod", and define a new 
"accessLocation" that uses a type other than a 
GeneralName->uniformResourceIdentifier and has the meaning "the location 
is the CertificateStatus TLS extension sent by the Server".
...or...
2. Define a new "accessMethod" that has that meaning.  (Not sure what 
we'd put in the "accessLocation" though).

Would this approach be any more or less likely to work with proxies?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Jun 2014 11:12:11 +0300

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

OK. Now I’ve had a chance to check this, and we don’t copy any of the policy extensions. We copy BasicConstraints, KU EKU and SubjectAltNames. That’s it.

Other vendors may be doing other things.

Yoav