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

[Phillip Hallam-Baker <[e-mail]>]

On Sun, Mar 31, 2019 at 7:36 AM Stephen Farrell <[e-mail]>
wrote:

> On 31/03/2019 08:39, Carsten Bormann wrote:
> > There is no free lunch in this space.
>
> Oddly, there sort-of is... if one ignores the ~every-5-years
> debate that the new-way (asn.1/der,asn.1/<foo>,xml+dtd,xml+
> schema,json,cbor...) is obviously the right answer to everything,
> and just go eat your lunch... then that's nearly a free lunch:-)
>
> I never understood how so many people get so excited by this
> topic myself. Seems to me programmers will always find a way
> to do as well or badly as ever despite the differences in this
> kind of tooling. (Training, experience and other kinds of
> tools like more strict compiler options can make a difference.)
>

Only five? Seems like every six months.

Yes, of course write a compiler to parse any data structure, especially IP
packets. I can guarantee you that IPv6 packet exploits will be a recurring
source of software vulnerabilities for decades into the future.


I have written several ASN.1 encoders and decoders over the years. My take:

1) I never touch ASN.1 unless I am being paid to do so and in advance. Nor
would I expect anyone else to do so.

2) ASN.1 is a very good idea in principle that is marred with some very
unfortunate practice that render it worse than useless.

3) Having six encoding rules is a defect, not a strength. The point of
standards is to remove choices that don't really matter. Having six
incompatible encodings makes it matter.

4) The DER encoding rules are botched. They require use of nested length
delimited fields for a start which is inherently insecure unless the
receiver checks every inner structure to make sure that it is correctly
nested inside the outer.

5) The botched DER encoding is even worse because the nested lengths is the
use of nested variable length length specifiers. This means that the only
efficient strategy for encoding ASN.1 is to fill the buffer in the REVERSE
order starting with the last item.

6) Since there is no advantage of using ASN.1 over other choices and you
will get three years of gripes and debates over schema peculiarities, the
only use I can find for ASN.1 is for the small number of legacy
applications that require it. The only one that I have not found to be
unavoidable being PKIX which requires the worst-of-the-worst DER encoding.

7) To add insult to injury, the canonicalization that DER encoding purports
to provide is of absolutely no value. If I am checking the signature of
octet sequence X, absolutely harm should come from the possibility that
there exist an octet sequence Y that has identical semantics which could
have been signed instead. Yes, I can construct ludicrous scenarios in which
that would be true but any system that relied on canonicalization is broken.

8) PKIX requires DER but does not provide a canonical form for a
certificate. You cannot strip an X.509 certificate to its elements, put
those elements into an X.500 directory and then reassemble the cert even if
you want to because the extensions are specified as a list, not a set.
Given that 1TB of SSD currently costs $125 and certificates are a few KB at
most, this would be a very silly thing to want to try in any case even if
there were any people still operating X.500 directories.