Damien Miller wrote:
On Thu, 9 Apr 2009, Peter Gutmann wrote:Nicolas Williams <Nicolas.Williams%sun.com@localhost> writes:[So far the only extensibility mechanisms that we have at that point in the protocol are: new protocol version number (not going to happen) and magic algorithm names (which have been used successfully).]... and the completely unused 32-bit flags field in the first message, which I mentioned previously :-).I think it would be much safer to define new cipher names for this.
I agree. I think that most straightforward idea would be to allocate cipher names to selected gcm ciphers so that if such cipher gets selected, it will have side-effects to packet format that will be in effect after the subsequent NEWKEYS packet.
I don't support an idea to add some kind of "*" magic in order to offer gcm functionality over the existing algorithms (proposed by Kivinen).
I also think that using an independent cipher to encrypt packet lengths is not worth impelemting. Replacing cipher+mac with gcmcipher+cipher is just not worth it.
Actualy quite a few problems have arisen earlier from the fact that SecSh has encrypted packet length fields (which TLS doesn't have). However simply omitting packet length encryption would also require very careful consideration, because of various potential authentication related issues (password length snooping etc.).
I will think about this in more detail next week and try to think some way around the obvious caveats.
-- Timo J. Rinne <tri%ssh.com@localhost> Valimotie 17 +358 20 500 7000 T Chief Technology Officer FIN-00380 Helsinki +358 20 500 7397 F SSH Communications Security Corp. Finland http://www.ssh.com