[SSL Observatory] Fixing Revocation, security policy

[Phillip Hallam-Baker]

Well my idea of running a CA involved lots of layers of physical protection,
biometrics, uniformed guards and armies of auditors.

If I had had my way that would have been the bar that the browsers would
have insisted the new entrants meet as well. Instead they decided that it
would be sufficient to have an audit regardless of what the security policy
was. So if your security policy was that the CEO would fly round the world
with the root HSM in his handluggage, that would be OK.


Anyway, this is something that we need to fix regardless of what the
mechanism that is in place to authenticate the keys.

An essential starting point is to partition off the issue and validation
tier from the external facing Web site and then put in place controls that
ensure that all messages between the two are strictly controlled and
audited.


This is something that would be good as a general purpose device to prevent
application layer compromise in other circumstances as well.

I am a little wary of application layer firewalls as being too big and
complex for my taste. Also there is the risk that they are compromised in
the supply chain.

I am looking at a smaller and cheaper solution.


What would be ideal is to have a 'default deny cable' between the external
tier and the internal tier that:

1) Had measures to prevent control/data conflation attacks (i.e. code
injection)

2) Logged every message that passed across it

3) Enforced one way communication of the messages (no communication in the
reverse direction)

4) Enforced rate limiting controls

5) Had tamper evident packaging equivalent to the tamper evident
requirements of FIPS 140-3 level 3 or 4.

6) Could be produced for less than $500 each

7) Had protection against timing attacks and power analysis should it be
necessary to put a private key in the device (I suspect that this is not the
case).

8) Had code signing/verification built into the platform.

9) Was open source for both hardware and software

10) Was compact enough for a code audit to be practicable


Currently something based on the Netduino looks like the best bet.

Most application layer attacks come from code/data conflation and those
attacks are in turn mostly due to code injection or buffer-overrun.

So the role of the default deny cable is to check messages to ensure that
they have the correct syntax, that none of the data fields exceeds the
permitted size and that each and every command is properly guarded with a
prefix and postfix nonce value and that the values match.

If the message is conformant it is logged and passed across the cable.

For the data volumes we are considering it would take a very long time to
fill up a 2Gb log file. The log file would be emptied from time to time.

It is easy enough to set up a mechanism that ensures that the log file can
only be cleared once confirmation has been received from the offsite storage
location.


On Thu, Sep 22, 2011 at 10:22 AM, Peter Gutmann
<pgut001 at cs.auckland.ac.nz>wrote:

> Phillip Hallam-Baker <hallam at gmail.com> writes:
>
> >The CAs I have worked with have always known the set of issued certs.
>
> The CAs *thought* they knew the set of issued certs.  As did DigiNotar.
>
> >It was not an issue.
>
> It wasn't an issue with DigiNotar either, until suddenly it was.
>
> >What is the error response that a CA is meant to give when it receives a
> >status request for a cert it knows was never issued?
>
> According to OCSP either "not revoked" (confusingly labelled "good" in the
> spec) or "unknown", depending on how the implementer feels at the time.
> Relying parties can interpret this in any way they want, frequently as "the
> cert is valid" since it's not "revoked".
>
> (People were arguing over what the status values in OCSP meant long before
> it
> became an RFC, so this isn't a new issue).
>
> >If there isn't one we should fix OCSP in PKIX. I believe that was planned
> in
> >any case.
>
> PKIX have stated on several occasions, quite definitely, that they don't
> want
> this changed and won't change it.  Thus my earlier comment about finally
> being
> able to see what happens when hard reality collides with PKIX fantasy.
>
> I think your comment:
>
>  If there isn't one we should fix OCSP in PKIX.
>
> should really be phrased:
>
>  If there isn't one we should fix PKIX.
>
> A reformat and reinstall would be a good start [0].
>
> Peter.
>
> [0] Actully that's probably not the best approach.  At the moment PKIX
> serves
>    as a convenient tarpit for a bunch of people who would be causing a
>    tremendous amount of damage if they suddenly decided to stick their oars
>    into other standards groups.  So it does serve a useful purpose, and
>    disbanding it would probably be a bad idea.
>



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