[Cryptography] Heartbleed and fundamental crypto programming practices

Phillip Hallam-Baker hallam at gmail.com
Sun Apr 27 18:31:48 EDT 2014


On Sun, Apr 27, 2014 at 12:34 PM, Jerry Leichter <leichter at lrw.com> wrote:
> On Apr 26, 2014, at 9:21 PM, Christian Huitema <huitema at huitema.net> wrote:
>> There was indeed lots of gratuitous complexity in ASN.1. Why was there a
>> need for SEQUENCE and SET, or a distinction between SEQUENCE OF and SET OF?
>> Why was there a need for both IMPLICIT and EXPLICIT tags? Why where there
>> three types of tag numbers? Why have two ways to encode the length of a
>> structure type? The worse was probably the extension method.
> There are a number of things that lead to these kinds of designs (which are often, but not always, standards).  It's not "design by committee" as such.  There are committees that produce excellent designs; there are individuals who produce horrible ones.  It's a question of who's involved and what their motivations are.  Among the things that produce bad results:
>
> 1.  The designers are big names who no longer actually implement anything, but feel the need to justify theories about design that have worked for them in the past.  (Often, the theories are post hoc explanations for past successes and have little causal connection to those successes.)
> 2.  The designers fairly recently implemented something very much like what is being designed, know all the problems they ran into, and want to get it *right* this time.  They fall for a variant of Second System Syndrome.
> 3.  There are multiple people who can say "yes", but no one who has the authority to say "no".  This leads to compromises of the form "I'll OK your proposal if you OK mine."
> 4.  There are multiple designers in each subdivision of the spec, they have different ideas about the best approach (counted length vs. terminating sequence, for example).  Since each is "as right" as the others, and each is "as easy to implement" as the others, they all make it in as alternatives.
> 5.  If you're talking standards committees, politics (the same people tend to be involved with each other for multiple standards) and money (companies have their own technologies and want them included in the standard so they don't lose their investment) come in as well.
> 6.  Once a certain threshold of complexity is reached, it becomes extremely difficult to argue against one more "small" addition.  If the spec is two pages, everyone can see that a new alternative that takes a paragraph to describe is a big deal.  If a spec is two hundred pages, it starts to become difficult.  By 1000 pages - hey, why not add it.
>
> I'm sure there are others - and in the case of crypto, we strongly suspect that in addition to all the usual factors, there's been active subversion as well.
>
> For a design to succeed, the designers have to be committed to *it's* success, not to their own.  One-person designs have an edge because the two overlap.  Groups with strong tyrants as leads can succeed for the same reason.  These can also fail badly if led in the wrong direction.


I can see something like that going on right now with the DNS Privacy
work. This starts from a requirement for privacy and so one approach
is likely to be encrypting the connection between the client and the
resolver.

There are various approaches that could be used there but these boil down to:

1) Use TLS (and thus DNS over TCP)

2) Use DTLS (and stick to UDP)

3) Develop a new security enhancement.

Now the fact that TLS has been going on for 20 years leads to the
assertion that TLS is the simplest approach. BUT TLS is optimized for
a totally different application and performance is going to be poor
because every TCP connection is now going to require two TCP startup
sequences, one for the DNS transaction and another for the connection
to the discovered endpoint.

OK so what about DTLS, it is built on TLS right? Well sorta. It has
all the complexity of TLS and 20 years of barnacles clinging to the
hull. It is built on a PKIX trust mechanism with DNS grafted in badly.
And it is actually designed around applications like chat and gaming
where people really want TCP connectivity but are using UDP to work
round firewalls.

>From a designer standpoint I can guarantee that making TLS or DTLS
work for an application where they are not suited is going to be
vastly more complex than designing something that is purpose built.
But you can imagine what the arguments are going to be like 'go with
what we understand'. Which actually means 'I don't understand anything
about this stuff so I want to stick with what exists'.

Its only the message packing mechanism that is a poor match to DNS. We
can easily establish something that is essentially a shared secret
bound to a kerberos ticket like identifier and use that to enhance the
messages.


But it gets worse. The original framing for the problem is encryption.
But my objective is actually authentication. Because for me
authentication is worth ten times encryption. I am far more concerned
about making sure that Erdogan in Turkey can't block Twitter than
stopping him seeing the DNS traffic as the IP traffic that follows
will show who is going to Twitter. Being able to guarantee a link to a
resolution and discovery service you trust should be the foundation to
all other security, including the ability to hook in censorship
busting transports like TOR.

If we are going to encrypt packets then we need to do a key exchange
and establish a shared secret. Once we have a shared secret, encrypt
and authenticate is pretty much the same complexity and difficulty as
encrypt only. Adding a MAC to a packet is not a lot of effort.


But I know what the pushback is going to be; MAKE IT SIMPLE! Because
the last problem that arose in the USA was privacy that is the only
problem we are going to allow to be discussed. Any proposals to do any
other security will be rejected as OUT OF SCOPE. Because stopping what
the NSA might do is much more important than stopping what we know is
going on in Iran etc.

And then when the fact that we need authentication becomes obvious we
will go through a process of defining extensions to the core to allow
for authentication. And so what should have been mandatory to
implement is now an option. And options never work as well as
something that is required.


One of the reasons that PKIX is so complicated is that at every step
of the way there was someone insisting that the spec be made simpler
than the problem. And so we ended up with CRLs and OCSP rather than
one mechanism. And later SCVP was added on top.

With SAML we got to put together a core that was vastly more flexible
and capable than was necessary to solve authentication and
authorization. As a result SAML has remained pretty simple because
there was no need to invent ad-hoc work arounds for stuff.


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


More information about the cryptography mailing list