Subject: Re: [openpgp] "OpenPGP Simple"

From: Peter Gutmann <[email-masked]>
Date: Sun, 22 Mar 2015 15:48:17 +0000

Gregory Maxwell <[email-masked]> writes:

>A CA has signed an intermediate CA cert which is loaded in an interception
>appliance.  You blacklist this certificate by ID. Your blacklisting is
>bypassed by simply changing the encoding of the  when sending the cert chain
>and now your traffic can be intercepted again.

This issue has been known for a long, long time (well, I guess not by the
OpenSSL authors :-).  The problem is its being tied to a blacklist-based
security mechanism, you can always evade the blacklist through trivial
encoding changes that produce a valid but not bit-for-bit identical encoding.

Since all of PKI is built around blacklists (the second dumbest idea in
computer security, and arguably a special case of the dumbest idea in computer
security, default-allow), the PKIX folks argued that using certificate
fingerprints to uniquely identify a cert wasn't allowed because it broke their
blacklist/default-allow based approach to things.

As a result, they identify certs via their serial numbers (so a CRL isn't
really a CRL but a SNRL, a serial-number revocation list).  So now, instead of
a single easily-identified problem (trivially fixed by not relying on
blacklists for security), you have a whole raft of problems, many of them
still waiting to be discovered.

In other words the PKIX approach is to decide on a wrong solution
(blacklists), and then to break other things (certificate IDs) in order to
perpetuate the wrong solution.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 22 Mar 2015 12:01:53 -0400

> perpetuate the wrong solution.

No, the idea in PKI is that certificate issue is a whitelisting. So
CRLs are then a blacklisting of previous whitelist entries.

I don't think it really matters though as short lived certs are going
to be the basis for the emerging PKI/2. The need for certificate
revocation lists goes away just when I work out how to compress them.

If we could agree on one way to calculate a fingerprint of a key that
can be used for both OpenPGP purposes and PKI/2 then we can get the
systems to interop very nicely.

---

From: Gregory Maxwell <[email-masked]>
Date: Sun, 22 Mar 2015 16:17:20 +0000

> This issue has been known for a long, long time (well, I guess not by the
OpenSSL authors :-)

Yes, it was known by me in advance of that CVE as well.

> perpetuate the wrong solution.

And yet, in the end of the day users who thought they were secure are
left insecure.

How many years of compromises must people be subjected to before we,
in industry, become mature enough to develop systems which remain
secure _in practice_ in the face of design and implementation errors
by avoiding designs which have repeatedly resulted in breaks and
defending in depth?

We cannot know in advance what procedures and protocols people will
build in the future. If our abstractions are less safe-- if they have
a large amount of surprising hidden behavior such as non-canonical
encodings-- then the review requirements for anyone attempting to
build on them becomes unreasonably large and the amount of failure
will increase. The true complexity of a modern application is beyond
what any one mind can fully grasp at one time, we all must manage
complexity by abstraction, and some designs lead to safer abstraction
than others.

That an approach that was taken, like blacklisting, by a downstream
user of a cryptosystem design which stupid and wrong may also be true
and it's fine to also say that when it is so... But that fact does not
excuse specifying a protocol which is a footgun when it could have
been avoided with little cost (or, in the case of BER.. lower cost,
since a complete BER implementation is very complex). People will do
stupid things, from time to time, if our cryptosystems can only be
secure with completely perfect use then we might as well give up and
go home because perfect use will not happen and demanding it at all
times is an unreasonable cost which can easily outweighs the benefits
of the tools.

Sometimes there is a trade-off where there is a exclusive choice
between a valuable feature and a footgun. In those cases, it often is
reasonable to accept the footgun.

I have _never_ seen such an argument for overcomplete encodings; other
than for the sake of compatibility with legacy systems (for
cryptographic tools this compatibility is inevitably lost due to other
reasons, like the legacy systems being insecure). The overcomplete
encodings massively increase the review and testing burden (the usual
response is to just fail to test sufficiently) and as a result hide
bugs. They inherently increase the communication overhead (not that it
matters, the context where they come up are are usually very
inefficient to begin with) when they are possible, but subsetting them
out (like DER does to BER) hardly increases the overhead compared to
'optimal' use.

Sadly, it is infeasible to uncover in advance all the corner cases in
a spec that will surprise people and contribute to vulnerability; but
in cases where we've /seen/ problems in the wild we should not respond
by blaming the victims that misused the use fragile constructions,
once we know they're fragile we should avoid them where possible.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 22 Mar 2015 14:04:31 -0400

In this case the security problem was created by an unjustified assumption that the relying party would verify the canonical encoding 

So no, this is a problem the canonicalists caused. 

Sent from my difference engine

> On Mar 22, 2015, at 12:17, Gregory Maxwell <[email-masked]> wrote:
> 
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp