Re: [TLS] Heartbleed / protocol complexity

[Nico Williams <[e-mail]>]

On Wed, Apr 9, 2014 at 4:25 PM, Hanno Böck <[e-mail]> wrote:
> It's kinda surprising that nobody yet started a thread on the biggest
> issue in TLS these days on the TLS WG list. So I make a start.

Standard IDL + standard encoding + tooling == this type of problem
mostly goes away and it's easier to test and fuzz test unit
components.

TLS has an ad-hoc IDL and encoding, and it IIUC doesn't adhere to its
own conventions tightly enough that we could now standardize a
compatible IDL+encoding and develop tooling for it.

To all who have ever poo-poo'ed ASN.1 and friends I now say: you've
definitevly lost the argument.  If you don't like one IDL, use
another, or develop a new a new one.

> I see a number of issues here:

I don't agree with all that you say, but even if I did, all of these
issues pale by comparison to the IDL/encoding issue.

> * Extensions make the protocol more complex. Complexity adds attack
>   surface. [...]

Maybe, but we need extensibility, sometimes to get us out of a hole.
No extensibility == insecure fallbacks in the future.

There are no right answers in some cases.

> * Heartbeat adds some completely unneccessary complexity by having a
>   payload with an arbitrary length. There's no point in that. Fefe
>   wrote something about it (german only):

I don't think it's unnecessary: at least for DTLS it is probably
necessary for PMTUD.  If we have no use for it in TCP it might be
worth turning it off there, but that's fighting the last war by moving
complexity elsewhere -- the more DTLS and TLS diverge the less common
code can be shared.

Nico
--