Re: [Acme] ACME or EST?

[Nico Williams <[e-mail]>]

[Apologies for the noise.]

On Tue, Nov 25, 2014 at 04:08:21PM -0800, Tony Arcieri wrote:
> On Tue, Nov 25, 2014 at 4:03 PM, Paul Hoffman <[e-mail]> wrote:
> 
> > There you go. :-) Folks who have fought with ASN.1 longer than JOSE find
> > CMS's "handful of problems" already solved
> 
> More generally, there were two severe vulnerabilities discovered this year
> related to ASN.1:
> 
> https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/meyer

I don't see where that refers to anything to do with ASN.1 or BER/DER.

> http://www.intelsecurity.com/resources/wp-berserk-analysis-part-1.pdf
> 
> ASN.1 is *not* "LANGSEC-friendly". JOSE comes a lot closer. For that reason
> alone, ASN.1 is inferior.

ASN.1 is just syntax.  *BER* is the horror, as are all tag-length-value
encodings (Protocol Buffers, I'm looking at you too).

ASN.1 types can be encoded by XML, and there's even JSON encoding rules
proposals floating about for ASN.1.

If you like XDR/NDR/... (or TLS' ad-hoc encoding) you might like ASN.1's
OER.  XDR and OER are siblings; XDR is the bigger brother.  (I hope some
of you get that awful joke.)

The *nice* thing about ASN.1 is the availability of tooling -- yes,
decades late, to be sure, at least for decent open source tooling, but
still, it exists now.  That's not nothing.  Tooling is the answer to
hand-coded encoder/decoder accidents.

I'm curious as to what type(s) of _encoding rules_ you think is good for
security.

Assuming (wrongly?) a need for bags-of-bags-of- bags-of-...-of-scalars
generality, I see these kinds of encodings, historically:

 - tag length value: BER and sisters DER and CER, Protocol Buffers, ...
    - with definite lengths: DER, Protocol Buffers
    - with indefinite lengths: CER)

 - textual friends of TLV: XML, JSON

 - fixed-sized fields everywhere possible: XDR, NDR, OER, PER, and
                                           FlatBuffers [I think])

 - ad-hoc fixed-sized fields everywhere possible: IP, UDP, TCP, TLS,
                                                  SSHv2, ...

All of these are equivalent to each other in some way.  E.g.,
FastInfoSet is a compact encoding of XML using OER.

What types of encoding am I missing?

BER/DER, XML, XDR, NDR -- all of these have had notable security
vulnerabilities in decoding.  I'm not sure if JSON has had any though...

...oh, wait, no, JSON _has_.  Yes, even if you exclude 'Ruby', 'Rails',
and 'YAML' from your search, you'll find JSON parser security bugs.

Even Protocol Buffers implementations have had decoder security bugs (a
brief search turns up at least one, but I bet there's been more than one).

My question should really be: what types of encoding am I missing that
fit the bill (bags of bags of ... stuff) and are inherently safe(r) to
parse?


My take is that TLV is worse for security than any other encoding
because there's too much redundancy:

 - the 'T', which is redundant relative to the schema that generally one
   must know anyways), and
 - the lengths ('L'), which are all too easy to use without proper
   bounds checking.

   All encodings that can encode arbitrary-size data (i.e., all useful
   ones) will have to encode lengths internally, but TLV encodings tend
   to encode many more lengths than are needed.


IMO, this makes a good encoding:

 - a schema is needed to decode/parse because tags are not used
 - fixed sized fields are be used wherever possible, even if it's
   somewhat wastful
    - in particular fixed-sized integer fields (in powers of two bit widths)
 - fixed sized lengths are used wherever lengths are needed
 - adjacent booleans are packed in obvious ways
 - optional/defaulted field absence/presence encoded as booleans early
   on in each struct/whatever
 - no sets (on the wire there's always an order in which things appear)
 - good docs

   (the ITU-T x.68x and x.69x docs are actually quite good _references_
   once one gets familiar with them...)

ASN.1 has a good such encoding: OER.

A good syntax is one that's easy to write parsers for.

A *good* reference implementation is always needed for both, the syntax
and the encoding rules, because programmers always screw up (which
brings us to verifiable implementations...).  And that's needed in
multiple programming languages, with extremely liberal licenses, they
must be free in all senses, preferably verifiable, and definitely
portable.  No wonder these bugs keep happening...

Nico

PS: I'm not a fan of ASN.1 as a syntax.  It works well enough as long as
    one sticks to base x.680, but add in the Object Information System
    syntax and it gets messy fast (the tiny bit of ASN.1 in RFC7030
    shows this clearly).  But I am a fan of its expressiveness and
    generality, and I prefer it over ad-hoc syntax and encodings.

    Also, syntax is not that important: one can always create a better
    equivalent.  Encoding rules are forever.