Subject: Re: [therightkey] Certificate Transparency Working Group?

From: Santosh Chokhani <[email-masked]>
Date: Fri, 7 Sep 2012 08:02:29 -0400

Ben Laurie,

I am posting this at the suggestion of Stephen Ferrell.  There is no evidence that he supports or is against my analysis.  He just thought this mail list is the appropriate place to make my point..

My basic tenet is that the OCSP certinfo extension being discussed in PKIX does not protect against RA compromise and may also not protect against CA compromise since the attacker who compromised the CA may be able to create an OCSP Responder certificate and either also put bogus OCSP pointer in the minted certificates or use DNS poisoning on the relying parties.

Thus, I think the certificate transparency is worth discussing.

Santosh Chokhani
CygnaCom Solutions

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Sep 2012 10:04:18 -0400

I think there are two questions here:

1) Is there industry interest in support for some form of CA transparency?
2) Is the Ben, Adam, Chris et. al. proposal the approach to take?

If the answer to the first one is 'no' then there is no point in a BOF
because it would be like having a WG to decide what colour to paint
the White House, however interested the participants might be in the
proceedings they would have no practical effect.

The second question is not nearly so important as the first. There has
to be some demonstration that the subject area is an IETF problem
rather than an IRTF one but discussions on which approach or which
approaches to take would seem to me to be exactly the sort of thing
that should be considered at the BOF. So the point raised by Denis
seems to be an argument for a BOF rather than against one. He is
interested in the subject area but is proposing a different approach.

Given that the plan is to shut PKIX down in the near future, I don't
see how it can address any of the OCSP responder approaches to
transparency. In addition to the proposal made by Denis, there is the
proposal I made with Rob and other folk have also raised from time to
time. It would seem to me that this set of approaches is something
that would be better served by addressing them in a new WG rather than
trying to squeak them in before PKIX sets up shop.

PKIX never had a monopoly on X.509v3 extensions so closing PKIX should
not mean the end of development there.

Comodo is interested in CA transparency, whether we could support a
proposal that requires us to share our customer lists with competitors
is a different matter. There might well be a deployment deadlock
situation inherent in the protocol, I can well imagine a situation in
which all the major CAs are willing to deploy after someone else
agrees to go first.

Another proposal that probably deserves some consideration is a germ
of an idea that Rick Andrews proposed on the CABForum public list (so
I will feel free to raise it here). Rick proposed that national CAs
issue a statement that they only issue certificates for one country
and so all others should be ignored.

Now there are many problems with that particular proposal, I don't
think that national constraints give a lot of leverage. But it is
possible that some form of 'CA root profile' or 'Certificate signing
certificate profile' that goes beyond client-enforceable constraints
might have value.

This gets to a problem I am having on my home network right now. It is
very difficult to work out what part of the system is causing the
periodic network storms because none of the components on the network
provide a description of what 'normal' operation actually is. Every
device on my network has the ability to perform a SYN flood attack at
periodic intervals. That seems like a very bad idea to me.

I think that Transparency is the next big idea in Computer Security.
Addressing core PKI first seems like the best approach as it is the
point where we get the most leverage.

Where my approach differs from Ben's is that he is proposing a scheme
(call it Strong Transparency) that allows clients to tell when they
are being spoofed and I am more interested in the problem of how to
make it possible for any party with the requisite resources to tell
when someone might be being spoofed (Weak Transparency).

The difference between strong and weak transparency is the resources
that we can bring to the task and the outcomes we can accept. Strong
transparency is limited to the information on hand at the client
processed according to set rules, Weak transparency can engage
information from any source whatsoever and apply proprietary analysis.

Since the only actions a client can take have a significant impact on
the user (warnings, deny access to site), Strong transparency requires
a very high degree of confidence in the result. False positives are
much less important in Weak transparency as the action taken is most
likely to be 'tell a human analyst who makes personal contact with the
CA in question'.

Another possibility is that we might bridge the gap between the two by
using some scheme like Omnibroker that moves the task of establishing
network connections out of the client completely. That provides the
immediate protection that ST offers while retaining the flexibility
advantage of WT.

My view is that Weak Transparency is the low hanging fruit here and
Strong Transparency is a hard problem. I am willing to spend time on
Strong Transparency but only if that does not preclude the Weak
Transparency approach.

I think we can definitely get some form of WT deployed that justifies
the effort involved. Getting WT deployment will help rather than
hinder deployment of ST as it will provide the necessary testbed to
tell what works and how well it works.

Given the reluctance of the browser providers to deploy revocation
checking properly, I have a hard time believing that browsers are
going to be hard failing on CT irregularities. So I rather suspect
that what we will end up with is a WT system plus a distributed
catenate certificate notary infrastructure that we don't use for this
particular task but is useful for many other tasks.

---

From: Chris Palmer <[email-masked]>
Date: Fri, 7 Sep 2012 08:36:17 -0700

> 2) Is the Ben, Adam, Chris et. al. proposal the approach to take?

I don't know if you mean me, but if you do, everyone should know that
I have not worked on CT. It's Ben Laurie, Adam Langley, and Emilia
Kasper. See e.g. http://www.links.org/files/sunlight.html.

I am a CT booster, of course. :)

---

From: [email-masked] (Martin Rex)
Date: Fri, 21 Sep 2012 07:50:57 +0200 (CEST)

> Thus, I think the certificate transparency is worth discussing.

Locating the OCSP server through AIA in the EE cert might be the
problem here.  Maybe the OCSP responder ought to be located
through an extension in the CA cert itself instead?

-Martin

---

From: Ben Laurie <[email-masked]>
Date: Fri, 21 Sep 2012 09:58:26 +0100

> through an extension in the CA cert itself instead?

That would make CT substantially harder, because then we'd have to
deal with authenticating chains instead of just EE certs - and EE
certs tend to have multiple authentication chains...

---

From: Ben Laurie <[email-masked]>
Date: Fri, 21 Sep 2012 10:33:43 +0100

> certs tend to have multiple authentication chains...

To be clear, CT does not deal with revocation itself, but there's
little point in detecting mis-issuance if mis-issued certificates
cannot be revoked!

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 21 Sep 2012 07:19:30 -0400

Agree and also in that case the solution is not robust enough from security standpoint.  The adversary needs to do DNS poisoning and then is in business.

-----Original Message-----
From: Ben Laurie [mailto:[email-masked]] 
Sent: Friday, September 21, 2012 4:58 AM
To: [email-masked]
Cc: Santosh Chokhani; [email-masked]
Subject: Re: [therightkey] Certificate Transparency Working Group?

On 21 September 2012 06:50, Martin Rex <[email-masked]> wrote:
> problem here.  Maybe the OCSP responder ought to be located through an 
> extension in the CA cert itself instead?

That would make CT substantially harder, because then we'd have to deal with authenticating chains instead of just EE certs - and EE certs tend to have multiple authentication chains...

---

From: [email-masked] (Martin Rex)
Date: Mon, 24 Sep 2012 17:25:58 +0200 (CEST)

Santosh Chokhani wrote:
> Ben Laurie wrote:
>> Martin Rex wrote:
>> That would make CT substantially harder, because then we'd have to deal
>> with authenticating chains instead of just EE certs - and EE certs tend
>> to have multiple authentication chains...
>
> Agree and also in that case the solution is not robust enough from
> security standpoint.  The adversary needs to do DNS poisoning and
> then is in business.

My comment was not directed at CT itself, but rather at the problem
of locating the OCSP server (plus determining authorized OCSP signers),
because it is entirely ignorant of mis-issued certificates.

The key that signed an EE cert is static and hardwired into the
CA certificate, so I see exactly zero problems with hardwiring an
(a) OCSP distribution point into the same CA cert and (b) identifying
a different CA key within that CA cert extension that is authorized
to issue shortlive OCSP signer certs, so that the CA key that issues
EE certs is no longer an unavoidable single point of failure.

-Martin

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Sep 2012 16:48:24 +0100

> EE certs is no longer an unavoidable single point of failure.

The problem is that if the OCSP server is not identified in the EE
cert, then a misissued cert can be revoked according to one chain and
not revoked according to another. This defeats the purpose of CT.

There is a question of what to do if the CA issues a cert with the
wrong OCSP server in it - the answer, IMO, is you revoke the CA cert,
since it clearly cannot be trusted.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 24 Sep 2012 12:16:09 -0400

On 24/09/12 11:48, Ben Laurie wrote:
<snip>
> not revoked according to another.

Disagree.

In OCSP, the issuer is identified by Name Hash and Key Hash, not by 
Certificate.

Even a single OCSP Responder could potentially give different responses 
to different clients, so I don't think having different Responder URLs 
in different chains would create a problem that isn't already there.

> This defeats the purpose of CT.
 >

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

---

From: [email-masked] (Martin Rex)
Date: Mon, 24 Sep 2012 18:17:56 +0200 (CEST)

> not revoked according to another. This defeats the purpose of CT.

Huh?  It would be silly if CT would depend on that.
Different to the CRL distribution point extension,
the OCSP AIA information is pretty irrelevant to OCSP, and does
not affect the "acceptable" OCSP signers at a..
There are efforts underway to send around stapled OCSP responses
where the OCSP AIA information will be completely ignored.

So it would be flawed to make anything dependent on the OCSP AIA
information in the EE cert.

> since it clearly cannot be trusted.

Wrong OCSP AIA information in a cert is at most a functional defect,
but by itself not a security problem.

However, I believe we're talking past each other.

The original concept in X.509 about revocation is that

 (a) it is assumed that mis-issuance can not possibly happen

 (b) if it happens anyhow, you'll have to nuke the whole PKI immediately
     and rekey every entity

(a) is dumb and (b) is an unnecessary royal PITA.

There are CAs that sign thousands and thousands of certs.  
The US DoD seems to operate several CAs that have > 1 million certs
listed on their CRLs.  I assume that the number of their active certs
is in the same range.  A CA with 1 Million active certs with a lifetime
of 3 years each would have to issue ~1000 certs per day (when issuing
certs on holidays as well).  So that will likely be an online CA.

I believe it would be sensible to manage revocation with a key that
is distinct from the CA key, so that when an attacker manages to get
certs mis-issued with the CA key, determining whether an EE cert&credential
is valid can be alternatively performed through that seperate revocation key.

It seems easier to secure a CA key for revocation that needs to be used
only around once per week and can work on a cert push model exclusively,
than to secure a CA key that needs to be used ~1000x/day in online CA
scenarios.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 24 Sep 2012 12:56:03 -0400

Steve Ferrell,

Help please.  Does this belong here or in PKIX?

Martin,

I agree with Ben that this discussion is not related to CT and hence if you want and Steve agrees, it is best carried out in PKIX.

What you say below is not how the OCSP RFC and clients work.  For security and for simplicity, OCSP delegation is done by using the same CA key that signed the target certificate in question.  Thus, it does not matter where the OCSP pointer is.  If the CA key or CA is compromised, you should not rely on OCSP to indicate mis-issued certificates.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, September 24, 2012 11:26 AM
To: Santosh Chokhani
Cc: Ben Laurie; [email-masked]; [email-masked]
Subject: Re: [therightkey] Certificate Transparency Working Group?

Santosh Chokhani wrote:
>>> problem here.  Maybe the OCSP responder ought to be located through 
>>> an extension in the CA cert itself instead?
>> 
> security standpoint.  The adversary needs to do DNS poisoning and then 
> is in business.

My comment was not directed at CT itself, but rather at the problem of locating the OCSP server (plus determining authorized OCSP signers), because it is entirely ignorant of mis-issued certificates.

The key that signed an EE cert is static and hardwired into the CA certificate, so I see exactly zero problems with hardwiring an
(a) OCSP distribution point into the same CA cert and (b) identifying a different CA key within that CA cert extension that is authorized to issue shortlive OCSP signer certs, so that the CA key that issues EE certs is no longer an unavoidable single point of failure.

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Sep 2012 01:26:07 +0100

> Steve Ferrell,

Who's he? :-) I'm gonna guess you mean me though.

> Help please.  Does this belong here or in PKIX?

I think this list is probably best devoted to issues related
to CT for the moment. This topic seems tangential, but if
folks think otherwise that's fine since we're in the process
of figuring what is or is not the scope of CT (amongst other
BoF questions).

There's also a proposed BoF in the OPS area (wpkiops list)
about operational aspects of PKI. Discussion about OCSP
might be relevant there, if you're talking about what real
deployed systems actually do that adheres to, or differs
from, what's written in RFCs.

As Sean said in Vancouver, he's closing PKIX when current
work is done (a decision with which I agree). I don't know
if your topic fits one of the existing close-out work items
there or not.

Cheers,
S.

> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Sep 2012 11:25:56 +0100

On 24 September 2012 17:16, Rob Stradling <[email-masked]> wrote:
> Even a single OCSP Responder could potentially give different responses to
> different clients, so I don't think having different Responder URLs in
> different chains would create a problem that isn't already there.

This is a fair point. I guess from CT's POV so long as the problem is
made apparent, and we have an issuer to blame, revocation is somebody
else's problem.

To cure this problem we need revocation transparency, of course :-)

---

From: Rob Stradling <[email-masked]>
Date: Tue, 25 Sep 2012 06:30:45 -0400

On 25/09/12 06:25, Ben Laurie wrote:
<snip>
> made apparent, and we have an issuer to blame, revocation is somebody

Agreed.

> To cure this problem we need revocation transparency, of course :-)

Yes!