Re: [TLS] TLS grammar checker?

[[e-mail] (Martin Rex)]

Nico Williams wrote:
> On Tue, Jun 18, 2013 at 7:05 PM, Bill Frantz <[e-mail]> wrote:
> > [e-mail] (Blumenthal, Uri - 0558 - MITLL) wrote:
> >>
> >> Having written my share of ASN.1 stuff (including parser/encoder with no
> >> known vulnerabilities :), I agree with Nico's assessment of ASN.1.
> >
> > No known vulnerabilities is a good start. Unfortunately a lot of software is
> > released with no know vulnerabilities but doesn't hold up under attack. It
> > is nice to hear of software that has survived attack with no known
> > vulnerabilities.
> 
> Automatic tooling is a better start.  I.e., ASN.1, XDR, IDL, ... compilers.
> 
> Ad-hoc syntaxes don't lend themselves to automatic tooling, so they
> tend to result in lots of error-prone hand-coding.

Syntax that is so complicated that it needs tooling is a problem by itself.
ASN.1 is squarely part of the problem space, not part of the solution space.

If you believe you can parse or encode X.509/PKIX just by using an
ASN.1 compiler tooling, then you probably have never even looked
at X.509/PKIX.  The devil is in the comments sprinkeled all over the
place where you have to tweak the compiler output in so many ways and
so many places that writing everything by yourself becomes quite a
viable alternative, and one that is free of hidden eastereggs.

While there exist a canonical ASN.1 DER encoding, decoding and re-encoding
Certificates and CRLs may often result in digital signature verification
failures.

Dealing e.g. with the Version field of CRLs in particularly entertaining:

   TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2


Look at what rfc5280 says about the CRL version field:

 http://tools.ietf.org/html/rfc5280#section-5.1.2.1

   5.1.2.1. Version

   This optional field describes the version of the encoded CRL.  When
   extensions are used, as required by this profile, this field MUST be
   present and MUST specify version 2 (the integer value is 1).

and then check the real world what today's CRLs look like:

 o The CRL from the CRL-DP of the Google Internet Authority
   (the CA that signs Google's Server certs, including https://www.google.com)
   http://crl.geotrust.com/crls/secureca.crl

   no Version field (and no CRL extensions)

 o The CRL from the CRL-DP of the VeriSign Class3 EV SSL SGC CA
   (the CA that signed https://www.verisign.com/)

   http://EVSecure-crl.verisign.com/pca3-g5.crl

   no Version field (and no CRL extensions)

 o The CRL from the CRL-DP of the Godaddy Secure CA
   (the CA that signed https://www.godaddy.com/)

   http://certificates.godaddy.com/repository/gdroot.crl

   no Version field (and no CRL extensions)


Now the question for the implementor what to accept:

  1) reject (=soft fail and ignore) all three CRLs above ?
  2) reject all CRLs that have an explicit Version v1 (0) ?
  3) reject all CRLs that have no Version field,
     but non-critical CRL extensions (this is explicitly allowed by X.509!!)

ASN.1 is more than enough rope to hang yourself, and a number of existing
specs that use ASN.1, hang themselves in more than one place.


-Martin