Re: [TLS] Heartbleed / protocol complexity

[Nico Williams <[e-mail]>]

On Wed, Apr 9, 2014 at 5:43 PM, Geoffrey Keating <[e-mail]> wrote:
> I can add a few more examples: compression and client-initiated
> renegotiation are two things that were optional to implement, and
> that some implementations didn't implement and were saved security
> vulnerabilities by not doing so.

I agree as to compression: we know well now that compression decisions
must not be done at any layer other than that which knows if it's safe
to do it, and that layer is never TLS.  (This doesn't mean that the
app couldn't request that some TLS records be compressed while others
not, but that would be needless complexity.)

I don't agree as to client-initiated renegotiation.  The problem there
is that the semantics of renegotiation were not well specified early
on, so the APIs that got built too easily ended up failing to be
capable of doing the necessary channel binding, so the channel binding
didn't get built.  (Causality actually went the other way here, I
know, but in so far as running code was the source of
specification...)

> I think perhaps the lesson to learn from this is that implementations
> should probably not aim to be 'complete' or 'full-featured' TLS
> implementations, but rather only implement what is needed for their
> target audience; and if they do implement features that only some users
> will need, disable them by default.

If you said that apps should get to specify which TLS features they
need I'd agree.  Non-implementation with no choice in the matter
simply leads to non-deployment of important features.  There's no need
to throw out the baby with the bathwater.

Nico
--