Re: [TLS] TLS grammar checker?

[Nico Williams <[e-mail]>]

On Tue, Jun 18, 2013 at 7:05 PM, Bill Frantz <[e-mail]> wrote:
> On 6/18/13 at 4:26 PM, [e-mail] (Blumenthal, Uri - 0558 - MITLL)
> wrote:
>
>> Having written my share of ASN.1 stuff (including parser/encoder with no
>> known vulnerabilities :), I agree with Nico's assessment of ASN.1.
>
>
> No known vulnerabilities is a good start. Unfortunately a lot of software is
> released with no know vulnerabilities but doesn't hold up under attack. It
> is nice to hear of software that has survived attack with no known
> vulnerabilities.

Automatic tooling is a better start.  I.e., ASN.1, XDR, IDL, ... compilers.

Ad-hoc syntaxes don't lend themselves to automatic tooling, so they
tend to result in lots of error-prone hand-coding.

What are you arguing for?  (Mind you, this really isn't the right
place...  that goes for me too)

>> The syntax itself is fine as far as security goes.  It's not terribly
>> easy to parse (so that's one reason not to use it), that's about the
>> only significant problem with the *syntax*.
>
> Here is the reason I worry. The harder things are to do, the more likely
> mistakes will be made. That is why I prefer simpler formats.

Formats or syntaxes?  Let's be clear.

And yes, the fact that ASN.1 is relatively difficult to parse (but not
that difficult) has been used as an excuse to not use it or not write
tooling for it and just hand-code BER/DER coders.  But I think in
retrospect that it's not really the cause of the problem.  More likely
the fact that it was a non-free standard for so long meant that many
people coded to it without a proper understanding if it, much less
access to tools for it.  But that's ancient history now.  What about
the present?  Why not use this or that not-ad-hoc syntax?

> While I'm bashing ASN.1, formats that allow infinite length data items are
> asking for buffer overruns.

Like JSON?  Parsers/decoders need to impose some reasonable limits.
But this is not where the buffer overflows come from.  The buffer
overflows I think you're thinking of mostly resulted from redundancy
in TLV encodings.

Nico
--