Re: [TLS] Rethink TLS 1.3

["Ryan Sleevi" <[e-mail]>]

On Thu, November 27, 2014 3:01 pm, Watson Ladd wrote:
>  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

Watson,

I don't think this argument is particularly germane, fruitful, or frankly,
entirely well reasoned. Your argument that it's a protocol issue because
there are implementation issues lacks consideration that implementation
issues exist regardless of the protocol. At best, you're writing a screed
against parsers in C, and while I suspect you'll find a receptive audience
to this particular idea, the TLS WG is not the place for it.

As a simple counter-point to your reasoning, consider the many (MANY) RCE
bugs in msasn1.dll or cryptologic bugs such as the (poorly named and
technically inaccurate) BERserker bug in NSS. ASN.1 is very much a
structured representation for which one can create static representations
of that lack any form of dynamic parsing. Indeed, many early ASN.1
implementations used exactly this - parsing the ASN.1 definition and
generating static parsers that were "bug free", in as long as the parser
generator was bug free. This is the same thing Tor is doing. There are a
number of deficiencies in doing so, and implementors moved away from it,
and as a result, many bugs when processing ASN.1 were introduced. However,
this is not an intrinsic property of ASN.1, but of how implementors have
chosen to implement.

Hopefully this will be the end of the discussion of this vein on the list.
I see Nikos has already explained why the Heartbeat construct was itself
exceptional and, ostenstibly, non-idiomatic and error prone. That does
not, however, apply to the entire protocol, and one can arguably write
non-idiomatic and error-prone structures in the majority of parsers out
there, but that doesn't mean we're all doomed to invent Yet Another Parser
Language.

If anything, your argument is best reduced to a "fixed width field"
argument, which has its merits, but also lacks any form of extensibility.
While some may see that as a Good Thing, I would suggest that the majority
do not view "lack of extensibility except via protocol update" to be an
inherently valuable trait.

Cheers,
Ryan