[Cryptography] Is ASN.1 still the thing?

[Nico Williams]

On Mon, Nov 13, 2017 at 09:56:40PM +0000, Judson Lester wrote:
> There's the langsec argument to be made that DER is fairly complicated to
> parse, and as a result many critical errors have been found in popular ASN
> parser generators. Specifically, the theory is that simpler Chomsky

That's true of all TLV encodings.  The issue is redundancy in the
context of nesting of structures, which leads to lots of lengths that
you must make sure to sanity-check before ever using them.

(This is just as true of protocol buffers as of DER, because PB is a TLV
scheme.)

The bottom line is that if you use *tools* to compile IDLs, then there's
no security concern from the use of TLV (or any other) encodings.

OTOH, if you're going to be hand-crafting a codec, well, first, best
not! and second, don't! and third, yeah, TLV is a viper pit.

> categories of languages should be used as protocol encodings, and that DER
> is context free. The largest proponents of this position, however, suggest
> using JSON on the grounds that it is context-sensitive - a claim which I've
> always been idly sure collapses if you insist on a normalized form, or even
> that fields not repeat.

"insist ... that fields not repeat" -- that's a tall order in JSON-land!

I'm not sure what you mean about a "normalized form".  Canonical form?
But JSON doesn't have a canonical form.

So I don't see those grounds for believing that JSON is less a viper pit
than DER.

I suspect that an analysis of actual security vulnerabilities in DER and
JSON codecs will show that JSON is in fact safer, unless we limit
ourselves to vulnerabilities in the past decade, then it might all be
even.

There were lots of old hand-coded DER codecs in the 90s that needed to
have their bugs shaken out, and mostly I think they have.  Perhaps the
only real difference for hand-crafted DER vs JSON codecs is that overall
know-how in the industry having improved had improved dramatically by
the time JSON came along.

> That said, using a regular language for a secure protocol seems sensible,
> and the parsers have been with us for a long time.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Exactly: it's a solved problem, unless you decide to re-invent solutions
to it, because then it's on you to write secure codecs all over again.

Nico
--