Re: JFK nit

[Tero Kivinen <kivinen@ssh.fi>]

danmcd@east.sun.com (Dan McDonald) writes:
> Sorry if this has been repeated before...

Yes, this was repeated when the IKEv1 was specified, and at that point
we decided to remove all padding. The reason was that most of the
material in the packets was still binary byte objects (certificates,
nonces, key exchange payloads, identities etc) or 8 bit or 16 bit
numbers. Also the parsing of the IKE payload compared to the
diffie-hellman / public key signing / verification etc is so fast that
it really doesn't matter. Disadvantage of padding is that it required
quite a lot of more code and caused all kind of bugs where
implementators did that incorrectly.

This was done around 1997 search for the archives for more
information. 

> > 4.1  Structure
> > 
> >    Each message is a string of tag-length-value elements concatenated
> >    together.  Tags are one octet.  Lengths are two octets, and specify
> >    the number of octets of the value.  Values are always integral
> >    numbers of octets.  All octets are in big-endian order.
> 
> 
> Ewwww.  This is not a good choice.  Modern machines work better with aligned
> data!  Say you have two nonce tags in a row (Ni, followed by Nr).  Say they
> start nicely on byte 0x10...
> 
> 
> 	0x10	<Ni tag>
> 	0x11	<Ni len msb>
> 	0x12	<Ni len lsb>  == 8 bytes
> 	0x13	Ni msb
> 	...
> 	0x1a	Ni lsb
> 	0x1b	<Nr tag>
> 
> I can load the whole nonce into a register, but I can't, because it starts at
> the byte-only-boundary of 0x13.
> 
> JFK authors, please address this problem.  If you want to discuss matters of
> bit-twiddling import, let me know!

Note, that neither IKEv1 nor the IKEv2 draft address this problem.
They both use unaligned structures all the time. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/