[Cryptography] Overzealous encoding

[John Gilmore]

Peter Gurmann wrote:
> Exactly.  If you look at some of the extensions used with TLS you can
> immediately see which ones were created by X.509ers because they've emulated
> the sort of mess you'd usually see done in ASN.1 in TLS' ad-hoc encoding. This
> makes the whole thing twice as bad, you now have an ASN.1-style mess combined
> with the need to hand-code a TLS ad-hoc parser for it.

It's instructive to print out some hexadecimal TLS packet traces and
then take a copy of the TLS RFC to try to understand what they
represent.  Paul Wouters and I did this while working on the TLS
out-of-band public key extension.  It's worth doing even one packet,
or two.  Sharpen your pencil and try it!

The first thing you'll notice is that the TLS RFC (2246) is written in
a "high level C-like language" style.  It lacks those simple to
understand ASCII-art octet boxes that appear in all of Jon Postel's
RFCs (for IP and TCP and such).  In other words, the main text of the
RFC doesn't show you ANYTHING about the encoding on the wire.  As in
ASN.1, that info is buried.  In TLS it interleaved in the
definition/description of the "presentation language" in section 4.

The second thing you'll notice is that there is an awful lot of
known plaintext in the packet traces.  As you decode the bytes,
a bunch of them will be totally predictable (like length values
and algorithm specifiers and version numbers).

As in the X.500 example Peter gave, the presentation language hides so
much information about the actual packet encodings that the designer
can get waylaid into sending dozens of bytes of predictable and
useless plaintext without even knowing it.  That tends to make Eve and
Mallory smile.

	John