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

["Dr. Pala" <[e-mail]>]

Hi Nico, all,

thanks to everybody for your messages - I think the conversation is very 
interesting. A complier for TCP/IP packet parser is really an 
interesting idea :D But only if we (just a joke, do not kill me!) use 
ASN.1 and define a TIED (TCP/IP Encoding Rules) :D

Back to be serious... At the end of this thread, you ask "/why build a 
new one/" ?

I think, but there might be other reasons I am not aware of, that the 
main argument was to save few hundreds bytes per certificate (but the 
first step was to change your certificates' profile as an interim 
solution - which in many environments you can not really do for many 
reasons.

... and this consideration reminds me about an observation that I have 
not brought up during the meeting, but I should have: the current trend 
in cryptography seems to be oriented towards the need to use larger 
structures (signatures and keys) to cryptographically authenticate data 
(e.g., certificates, etc.). I think that ECC was a pleasant aberration 
from this point of view that made everybody think we discovered gold - 
same or increased security at a fraction of the price! That is great - 
and we are all very happy we can now use a quite efficient 
crypto-systems like ECC. However, I think, things are going to change: 
most of the quantum-resistant algorithms come with increased signature 
and/or key sizes (up to 40K for signatures in some cases) or with new 
usage paradigms (stateful keys) that are not trivial to handle.

Besides the fact that I am all for being more efficient - the added 
efficiency (that frees more resources that can be dedicated to other 
tasks) can be leveraged to increase security and/or to provide more 
services without incurring in additional costs. However, my fear is that 
people will start to feel "comfortable" with the idea that the size of 
authentication data is very small and will start designing systems that 
do not take in consideration the envisioned evolution of crypto 
algorithms... leading to some inevitable disaster down the road.

In this view, maybe pushing for such an herculean effort to save few 
hundred bytes per certificate might come with costs so high (in terms of 
the needed changes to support the new format(s)) that would not justify 
its deployment, IMHO.

Last consideration about "This is why we hate DER, and we like 
CDDL/CBOR." statement - I think that each format has its own merits and 
downfalls (even the amount of code that exists out there that supports a 
format can be seen as a merit) and it is up to us to provide good 
indications about when and where the different formats make sense (i.e., 
it depends on the environment). For example, in most of my application 
the CDDL/CBOR approach would not be secure enough because of the 
"relaxed" nature of the parsers - but that is just one environment, 
other environments might have different reasons to deploy/use this 
format based on their requirements.

Bottom line I would say rephrase your statement to "In our 
environment/ecosystem DER is not the right choice because of these 
reasons ... the pair CDDL/CBOR, on the other hand, satisfies these 
requirements because .... "

Thanks again to everybody for the interesting discussion :D

Cheers,
Max


On 3/26/19 11:27 PM, Nico Williams wrote:
> On Tue, Mar 26, 2019 at 04:08:58PM -0400, Carl Wallace wrote:
>>>> This is why we hate DER, and we like CDDL/CBOR.
>>> Whatever the abstract syntax, the real solution is probably more
>>> widely available/used compilers.  Hand-rolled codecs will have more
>>> (frequent and subtle) bugs.
>> Fully agree with this. The first time I had to consume CBOR/COSE the
>> encoded structures were every bit as buggy as folks complain about DER/CMS
>> structures.
> I recently had to review a hand-rolled codec by a seasoned developer.
> It had a number of fatal security bugs, exactly as one might have
> expected (as I did, going in).  Hand-coding codecs is simply very
> difficult.  It's easier when you have "bits on the wire" specifications,
> like TCP/IP, or when you have XDR specifications.
>
> No one uses a compiler to generate TCP/IP packet parsers, though this
> is first and foremost a result of not having anything like a
> machine-readable formal language specification for TCP/IP packet
> headers.
>
> XDR is so darned obvious and simple that in Heimdal we have just library
> functions for it and simply don't have or need a compiler.  The
> traditional XDR compiler, rpcgen, is also very limited, so generally XDR
> codecs are hand-coded using well-maintained and well-tested libraries
> that make it easy.
>
> Something similar can be said of SSHv2's encoding rules.
>
> The ASN.1 packed-like encoding rules are XDR-like, though with 1-octet
> instead of 4-octet alignment -- these too are easier to hand-code, but
> because there's often an escape to BER (e.g., for encoding of lengths of
> fields that cannot have fixed lengths, or encoding OIDs), it's still
> tricky by comparison to XDR.
>
> But it is a very strong truism that, whatever the encoding rules, having
> a compiler for an abstract syntax that generates codecs with usable APIs
> and characteristics, is inordinately easier, safer, and less time-
> consuming than hand-rolling a codec for any encoding rules.
>
> It is also a strong truism that simple syntaxes with simple encodings
> admit safer hand-coding of codecs, but also that, by being informal,
> also typically preclude compilation.
>
> I would and do accept informal syntaxes and encoding rules for protocols
> like SSHv2, or TLS, because a) it's already done, b) the messages are
> simple enough, c) it's easy enough to build libraries that make mistakes
> unlikely, d) often the implementors do not believe they have access to
> proper tooling, e) having access to ASN.1 tooling doesn't help if the
> only ERs you get are TLV ones.
>
> CDDL is not an informal syntax.  For new formal syntaxes I have a higher
> bar just because it is very difficult to come up with something that
> ASN.1 does not already have -- unless there's a trivial mapping between
> the two.
>
> BTW, who can forget FastInfoSet?  That's... XML with transliteration to
> ASN.1 and application of PER as a compression of XML.  While XER is
> essentially the reverse: transliteration of ASN.1 to XML, with XML as
> the encoding rules.  These, for me, prove the point that syntaxes are
> likely interchangeable (so why build a new one?).
>
> Nico
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo