[SSL Observatory] so called "lawful intercept" survey

[Phillip Hallam-Baker]

This is actually one of the issues that led me to propose CAA in the first
place. If you recall there was an issue with a CA in the Middle East with
RIM being strong armed into giving the local security service a code signing
cert.

Threat of imprisonment by the government is not one that I think we can
realistically expect people to resist. That is why I refuse to accept the US
controlled DNSSEC hierarchy as the ultimate PKI authority. Whatever the
claims to the contrary, the ICANN root CA is under defacto US government
control. I know that there are lots of people trying to tell the gullible
that this is not the case but folk tried the same thing in the PEM days as
well.

It is really easy to propose a scheme that works better than the current
X.509/CA infrastructure if the old system is judged against the most
skeptical criteria and the new system is allowed to rely on the benevolence
and good conduct of an absolutely impeachable authority.

I have no idea why so many EFF folk are so willing to buy into the idea that
ICANN is totally trustworthy. But even if you trust Steve Crocker and the
next ten people who succeed him in office the question of whether ICANN can
maintain control is unanswered. Russia, China and Iran would be fools not to
lobby for the DNSSEC scheme because once a single point of control is
established it will be a trivial matter for them to usurp it within their
own territories.


The only way to control for the threat of government coercion is to ensure
that there is transparency in the control mechanism so that a default can be
detected and there is an alternative means of providing authentication in
the case that a default occurs.


On another tack entirely, Gerv's proposal is actually much wider than I
expect he intends since he attempts to outlaw all forms of support for
lawful intercept.

It is a matter of public record that VeriSign's telco division used to offer
support services for processing lawful intercept. What this entailed was
receiving the writ or subpoena, determining whether it was applicable, was
issued under the correct lawful authority etc.

http://xml.coverpages.org/NetDiscovery.html

In other words the design of the scheme was to ensure that warrantless
wiretaps did not employ the CALEA mandated support for lawful intercept.

Unfortunately the design of the US telco system is so awful and insecure
that it is a strong lock on a gate next to a huge hole in the fence. Thus a
system like NetDiscovery can stop criminal activity by a rogue cop or
prosecutor seeking to illegally bypass control. It cannot stop criminal
activity directed by the President or the Vice President and implemented by
the NSA since they can simply bypass the controls and issue the necessary
SS7 commands to redirect the traffic. Contrawise this fundamental insecurity
in the US telco system is almost certainly exploited by numerous friendly
and unfriendly intelligence agencies since the barrier to perform the attack
is actually rather low.


What is (I think) at issue here is the question of whether a CA would be
legally coerced to issue false credentials in order to enable a lawful
intercept. That is not something that has ever occurred as far as I am
aware.

So the statement needs to be much more specific.


On Thu, Sep 22, 2011 at 12:05 PM, Gervase Markham <gerv at mozilla.org> wrote:

> On 19/09/11 17:23, Jacob Appelbaum wrote:
> > The survey could be as simple as the following question:
> > "Do you offer any kind of product or services for lawful interception
> > solutions? If so, what are they and how do they function?"
> >
> > It seems in the browser vendor's interest to ask a related question:
> > "Does your business ever issue certificates to any party other than the
> > valid business associated with said certificates?"
>
> I assume you mean "valid business associated with the domain name in
> question"? If so, then my understanding is that Mozilla policy and the
> new Baseline Requirements both forbid such a thing - this seems obvious
> to me. However, if people think that the documents have a loophole that
> CAs are driving through, they should bring it to our attention.
>
> Also, I'd be surprised if CAs would do this, because of the risk of
> getting caught. You are basically issuing non-repudiable
> digitally-signed certificates of your malfeasance and then giving them
> to a customer to 'distribute' in a manner you have no control over!
>
> > I imagine it might also be worth asking the following as well:
> > "Does your business ever issue intermediate certificate authorities for
> > any reason?"
>
> Now _this_, on the other hand, is AIUI a common business model. Although
> again, if there were no contractual controls such that a scenario like
> the one above could happen, and it became known, the CA's reputation
> would take a significant hit if one of the certs came to light.
>
> On the back of all that, it seems to me that one of the best ways of
> keeping CAs honest would be for the various addons etc. floating around
> which check certificate correctness were to "phone home" to the addon
> author's organization with anything suspicious which was detected. If
> they were to do that, even a small takeup of such tools would make
> attacks like the Iran attack much easier to spot, much earlier - and
> remove any remaining reason for collaborating CAs to think they could
> get away with it.
>
> > It also seems prudent to ask about internal legal policies regarding
> > National Security Letters or similar attempts to force signatures. If
> > the internal policy is to simply hand over the keys or a HSM to law
> > enforcement, I'd also like to know those related facts. There are lots
> > of corner cases here and all of them seem interesting points for
> discussion.
>
> Having made the points above, I would say that your idea of a survey of
> such practices seems an interesting one. (I can't promise that Mozilla
> will do it :-)
>
> Gerv
>
>


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20110922/dd3b9d84/attachment.html>