[147423] in cryptography@c2.net mail archive
Re: [Cryptography] TLS2
daemon@ATHENA.MIT.EDU (Bill Stewart)
Tue Oct 1 17:05:41 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 30 Sep 2013 21:36:27 -0700
To: cryptography@metzdowd.com
From: Bill Stewart <bill.stewart@pobox.com>
In-Reply-To: <5249ECD6.6010000@echeque.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
At 02:27 PM 9/30/2013, James A. Donald wrote:
>On 2013-09-30 18:02, Adam Back wrote:
>>If we're going to do that I vote no ASN.1, and no X.509. Just BNF format
>>like the base SSL protocol;
>
>Granted that ASN.1 is incomprehensible and horrid, but, since there
>is an ASN.1 compiler that generates C code we should not need to comprehend it.
Unfortunately, you have to be able to comprehend all of the failure
modes and attacks on ASN.1.
The object descriptions themselves are a bit bloaty, with their main
weakness being that either
you have to get permission to attach your data into the official tree,
or else do a vendor-specific branch, but they're not all that broken.
It's the data representations that map them into binary strings that are a
wretched hive of scum and villainy, particularly because you can't depend on a
bit string being able to map back into any well-defined ASN.1 object
or even any limited size of ASN.1 object that won't smash your stack or heap.
The industry's been bitten before by a widely available open source library
that turned out to be vulnerable to maliciously crafted binary strings
that could be passed around as SNMP traps or other ASN.1-using messages.
Similarly, PGP's most serious security bugs were related to
variable-length binary representations that were trying to steal bits
to maximize data compression at the risk of ambiguity.
Scrounging a few bits here and there just isn't worth it.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
