Re: [TLS] Heartbleed / protocol complexity

On Thu, Apr 10, 2014 at 5:20 PM, Dan Brown <dbrown@certicom.com> wrote:
> Could some test vectors have helped prevent this bug?

Systematically ensuring that all invalid length combinations would
have triggered an error would have worked. That's more than some test
vectors. Furthermore, it's not clear how you supply test vectors to a
protocol implementation: it can be done, and should be, but it is
quite a bit of work.

What could have mitigated this bug would be not disabling OS
protection measures in malloc. Had OpenSSL not used their own malloc,
then on OpenBSD the malloc flags "FGJZ" would have significantly
reduced the impact of the attack, and quite possibly crashed the
process if exploitation was tried. (OpenSSL has bugs that are only
found when you disable their own malloc wrapper, which is why they
didn't do it).

Various proposals for taint analysis in C have floated around for a
number of years. However, qmail demonstrates that one can write secure
C code without this assistance. Even a typedef int untrust len,
followed by a compiler that warns of aliasing and a perl script that
brings special attention onto casts from this type (okay, not so easy
to write: you need to track declarations) would have been useful.

Furthermore, there was no need to implement heartbeats over TLS for
web servers. The TLS wire format is a pain to parse, and you need to
handle it even after ending the handshake.

However, the fundamental problem isn't anything more than the
developers of OpenSSL being lackadaisical about security. Entire
multiuser operating system kernels (xv6 to be precise) can be fitted
into one fifth the code size of OpenSSL.  PolarSSL is one tenth the
size, and does the same job. miTLS does a much better job, is in a
high level language, costs 10x as much in computation time, and is
guaranteed to be correct. (It doesn't do X509 verification however,
and I don't believe side channels are reasoned about: both are fixable
without much more code).

Sincerely,
Watson Ladd

>
> Sent from my BlackBerry 10 smartphone on the Rogers network.
>   Original Message
> From: Hannes Tschofenig
> Sent: Thursday, April 10, 2014 7:55 PM
> To: Martin Thomson; Hanno Böck
> Cc: tls@ietf.org
> Subject: Re: [TLS] Heartbleed / protocol complexity
>
>
> Hi Hanno,
>
> I agree with Martin regarding your the statement about simplicity. We
> always try to make extensions as simple as possible. Questions that come
> to my mind are: Have you provided comments at the time when RFC 6520 was
> written? Have you helped to improve the OpenSSL implementation of RFC 6520?
>
> There is an underlying problem that needs to be addressed, namely that
> we produce specifications but once we are done with the specifications
> we (as an organization) don't seem to care about what happens
> afterwards. Someone there is the impression that the developer community
> implements our protocols quickly and in the way we want. Assuming the
> existence of code that is available to the public does not necessarily
> mean that it is bug-free.
>
> We have many examples of this behaviour throughout the IETF (i.e., there
> is nothing unique to TLS).
>
> In the past I had argued that we need to take the transition from the
> specification (paper) to the actual implementation a bit more serious
> but, unfortunately, I found very little support for it. Just to give you
> a pointer to my most recent write-up on this topic have a look at my
> STRINT paper: https://www.w3.org/2014/strint/papers/62.pdf
>
> Ciao
> Hannes
>
> On 04/09/2014 04:28 PM, Martin Thomson wrote:
>> On 9 April 2014 14:25, Hanno Böck <hanno@hboeck.de> wrote:
>>> If it is decided that a new extension is needed it
>>>   should be as simple as possible.
>>
>> That's a motherhood statement.  Yes, RFC 6520 could have been simpler,
>> but it does provide a valuable function.  The payload included.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin