Re: [TLS] Heartbleed / protocol complexity

Could some test vectors have helped prevent this bug?

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
>