Re: [TLS] Rethink TLS 1.3

[Watson Ladd <[e-mail]>]

On Thu, Nov 27, 2014 at 1:04 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> On Wed, 2014-11-26 at 16:03 -0800, Watson Ladd wrote:
>
>> >> Parsing TLS is one of the biggest issues in implementations. I can't
>> >> promise to write the tool to auto-generate the parser, but we should be
>> >> sufficiently chastised by all those who tried and failed to parse TLS
>> >> records with handwritten C to consider not doing it ourselves.
>> > Where does this come from? TLS is one of the easiest protocols to parse.
>> OpenSSL couldn't parse an echo request correctly.
>
> This is a TLS extension and is known to be unnecessarily complex. It
> proves nothing about the TLS parsing complexity that you mention.

The construct of a heartbeat payload is a vector. It's simpler, not
more complex, than many structures in TLS.

>
>>  Many of recent CVEs
>> in OpenSSL have been related to corner cases in parsing. Microsoft got
>> bitten by a memcpy that didn't check its length. If it was easy to
>> parse, we wouldn't have parser bugs when parsing it. CVE-2014-3466
>> looks like a GnuTLS parser issue to me, and there are plenty of others
>> to pick from.
>> Who wrote the buggy code? Well, one Nikos Mavrogiannopoulos according
>> to git-blame. Maybe parsing TLS with handwritten C is not so easy,
>> after all.
>
> I believe you try to generalize based on your very limited view. Of
> course there will be bugs, and I guess there will be more by that author
> but there will not be any protocol that cannot be implemented
> incorrectly. However, you cannot prove your point in the complexity of
> TLS record parsing, by pointing to one parsing bug in the 14 years of a
> project. What does it make you think this is a recurring issue?

The fact that every single implementation I can think of has had RCE
or memory leak resulting from parsing errors, and usually quite a few?
This doesn't sound like an easy task: it seems downright difficult if
a lot of talented people can't do it. The Tor project is working on
writing parser generators that can deal with the sort of structure we
seem driven to produce in binary protocols for precisely this reason.

Contrast TLS to this http://curvecp.org/packets.html, or
https://tools.ietf.org/html/rfc2812#section-2.3.1. In the first case I
chop out a header, and the rest is a message content: because
everything is fixed width except the last field, no tricky issues. In
the second case I can use yacc.

It's probably too late now, but we need to at least not make the problem worse.

Sincerely,
Watson Ladd

>
> regards,
> Nikos
>
>



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