[cryptography] preventing protocol failings
nico at cryptonector.com
Tue Jul 5 11:03:40 EDT 2011
On Tue, Jul 5, 2011 at 7:59 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> Nico Williams <nico at cryptonector.com> writes:
>>Why even have a tag?? The ASN.1 Packed Encoding Rules (think ONC XDR with 1-
>>byte alignment instead of 4-byte alignment) doesn't use tags at all.
> Which makes them impossible to statically check, and leads to hellishly
> complex decoders.
That was my first reaction to PER also. But then I noticed the
similarities to XDR. XDR encoding/decoding is not terribly complex,
and has had a compiler and runtime for decades.
OTOH, PER *is* hellishly complex *if* you're not using a compiler to
generate PER encoding/decoding code. The problem quickly becomes how
to keep track in one's mind of the message layout.
>>In BER/DER/CER/XML you get a lot of redundancy: tag-length-value, sometimes
>>tag-length-tag-length-value (e.g., when explicit tagging is used).
> This is a feature, not a flaw, because it means you can statically type-check
> it. With BER/DER I can implement a filter that takes as input any encoded
> blob and reports true or false for the question "is this well-formed data".
> With CER (and XML, and PGP, and SSH, and SSL/TLS, and IPsec) I can't.
Not exactly true because most ASN.1 modules use lots of implicit
tagging. So instead of "tag for integer, length, integer value
octets" you get "context tag something or other, length, value" and
you have to know from context that the value is an integer instead of
In other words, in ASN.1 as it's used you have to know the schema and
message type in order to do a good job of parsing the message, and
this is true regardless of encoding rules (dunno about XER, that's
probably easier to parse w/o reference to the schema).
>>If you want to prevent new bugs in these areas, let's start with putting the
>>venerable BER/DER/CER to rest in the trash bin. Legacy will make that a
> BER and DER are actually the safest encodings of the major security protocols
> I work with. I'd rank them, in terms of danger, as:
> [Long gap]
> PGP, SSL/TLS
> [Smaller gap]
Given an ASN.1 compiler and BER/DER runtime I totally agree. But
there's way too much hand-rolled ASN.1/BER/DER code out there, and
there's been plenty of bugs (interop and security both) in that code
(MIT krb5, I'm looking at you).
The real lesson isn't that encoding rules must not be redundant, but
that tools are required.
Another lesson is that avoiding ASN.1 in SSH and TLS didn't exactly
help: every protocol that avoids an off-the-shelf syntax and encoding
rules ends up creating its own syntax and encoding rules, thus leading
to more complexity for implementors who have to implement more than
one of these protocols.
More information about the cryptography