Protocol implementation errors

[Peter Gutmann]

Jerrold Leichter <jerrold.leichter at smarts.com> writes:

>Both of these are helped by a well-specified low-level syntax.  TLV encoding
>lets you cross-check all sorts of stuff automatically, once, in low-level
>calls.  Ad hoc protocols scatter the validation all over the place - and some
>of it will inevitably be overlooked.

Yup, and that's exactly what makes me so nervous about the ad hoc formats.
Having had the experience of writing parsers for every major format used in
crypto (oh, except IPsec, but that falls into the same class as PGP/SSH/SSL)
and ranking things in the order in which I'd expect problems to occur, I get:

  ASN.1: Pretty much bulletproof, you should be able to throw anything at that
  code and it'll just bounce off (I should be able to run the recent
  malformed-ASN.1 attacks that hit OpenSSL on it within the next few days, but
  I'd expect all of those to be caught by the firewall and not even get to the
  actual ASN.1 code).

  Ad hoc formats (PGP, SSH, SSL): Should be OK because I apply anal-retentive
  amounts of checking everywhere and have done probably a dozen full audits of
  the code, but I'm still not fully confident about it (it did withstand the
  malformed-SSH-message weaknesses from a few months ago though).

  Text formats (XML): Full of arbitrarily-complex messages, variable-length
  encodings, special-case escape sequences, and other horrors, and that's
  without even thinking about the nightmare added by XSLT, XPath, DTDs, style
  sheets, XML namespace problems, and who knows what else.  If anything goes
  wrong, it'll be in there.  I can't even imagine how you could produce a
  truly safe parser for that stuff.

While I'm not madly in love with ASN.1, in terms of safe data formats it's the
one I feel most comfortable with.

"Jonathan S. Shapiro" <shap at eros-os.org> writes:

>I agree that ASN.1 is statically checkable, and that this is an important
>property. However, ASN.1 is notoriously hard to parse, which leads to errors.

ASN.1 has a *reputation* of being notoriously hard to parse, gained chiefly
from some early bad experiences with OSI work (which would give anything a
reputation of being hard to work with :-).  I've implemented, and I know of
others who have implemented, extremely compact and portable ASN.1 libraries.
My ASN.1 library is about the same level of complexity as the PGP and SSH
libraries, so the bit-bagging scheme being used has little to do with it.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com