[18987] in cryptography@c2.net mail archive
Re: "ISAKMP" flaws?
daemon@ATHENA.MIT.EDU (Florian Weimer)
Fri Nov 18 16:59:21 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: Florian Weimer <fw@deneb.enyo.de>
To: William Allen Simpson <wsimpson@greendragon.com>
Cc: cryptography@metzdowd.com
Date: Fri, 18 Nov 2005 22:43:23 +0100
In-Reply-To: <437E1EF2.5040705@greendragon.com> (William Allen Simpson's
message of "Fri, 18 Nov 2005 13:35:30 -0500")
* William Allen Simpson:
> Florian Weimer wrote:
>> Photuris uses a baroque variable-length integer encoding similar to
>> that of OpenPGP, a clear warning sign. 8-/
>
> On the contrary:
>
> + a VERY SIMPLE "variable-length integer encoding", where every number
> has EXACTLY ONE possible representation (unlike ASN.1 which even the
> spell-checker wants to replace with assinine).
>
> + "similar to that of OpenPGP", the most common Open Source security
> software of the era, where the code could be easily reused (as it
> was in the initial implementation).
Even back then, the integer encoding was considered to be a mistake.
| I concur completely. I once got so fed up with this habit that I
| tromped around the office singing, "Every bit is sacred / Every bit
| is great / When a bit is wasted / Phil gets quite irate."
|
| Consider this to be one of the prime things to correct. Personally,
| I think that numbers should never (well, hardly ever) be smaller
| than 32 bits.
(Jon Callas, 1997-08-08)
>> The protocol also contains
>> nested containers which may specify conflicting lengths. This is one
>> common source of parser bugs.
>>
> On the contrary, where are internal nested containers in the protocol?
Variable-length integers within other fields, for example. You can't
avoid this phenomenon in its entirety, of course, without sacrificing
some of the advantages of a binary encoding.
> Again, the ISAKMP flaws were foreseeable and avoidable. And Photuris
> was written before the existence of ISAKMP.
I like ISAKMP as much as the next guy, but somehow I doubt that
simpler protocols necessarily lead to more robust software. Sure,
less effort is needed to implement them, but writing robust code still
comes at an extra cost. *sigh*
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
