Re: [saag] ASN.1 vs. DER Encoding

[Nico Williams <[e-mail]>]

On Thu, Mar 28, 2019 at 01:38:59AM +0000, Peter Gutmann wrote:
> Nico Williams <[e-mail]> writes:
> >A protocol using ASN.1 BER/DER/CER with IMPLICT tagging will lose some type
> >information, so while you can check a lot of an encoded message's validity
> >without reference to its schema, you cannot check all of it.
> 
> You can check it, you just need to use heurstics.  That's what dumpasn1 does,
> it's aware of the situations in which there's encapsulation and can dig down
> into both implicit-tagged data and hole encodings.

Yup.

> >Whereas if you have reference to its schema, then you can check all of it
> >regardless of whether the encoding rules are TLV or not.
> 
> And that's the problem, you need to have the schema for the latest version of
> every possible protocol you're likely to examine, and update the code every
> time anything anywhere changes.  With a self-describing data type, you only
> need to write the format firewall once and it'll work indefinitely.  I've been
> using the same ASN.1 firewall code for over fifteen years...

Consider extensibility markers: extensions your dumper doesn't know will
be skippable.  Or consider typed-holes: if a hole contains something
that isn't BER, dumpasn1 won't be able to understand it.

Non-TLV encodings exist and get used.  NFSv4 uses XDR -- not TLV.  CBOR
isn't TLV and you can see it's likely going to get used for important
applications.

At some point a generic dumper needs to know the various schemas, and
hopefully it can figure out contextually the type of the outer-most
value and then use schema to drive the rest.  Once you accept this your
dumper no longer needs heuristics.  Keeping up to date is no different
than keeping any TLS/whatever library up to date, but it's easier
because there are no compatibility requirements (it being just a
dumper).

Code bloat is not really an issue.  The Heimdal ASN.1 compiler has an
option for something it calls "templates", but which is really a bit
more like a bytecode compiler and interpreter.  That reduces code size
(because the bytecode is much smaller than the alternative generated C)
and improves performance (for the same reason, which reduces pressure on
the instruction cache).  With byte-compiled modules you could afford to
have all of them built-in to the dumper, and you could even make new
modules downloadable.

Nico
--