Re: [tcpinc] tcpcrypt MTI key exchange (speak now or forever hold your peace...)

[David Mazieres <[e-mail]>]

iang <[e-mail]> writes:

> In general +1.
>
> The only quibble I would have is that 2. Curve448 should be a MAY. 
> Firstly, a caveated SHOULD becomes a MAY, at some level of 
> approximation.  Secondly, if we manage to convince an enemy to crunch 
> Curve25519 then we have won a great victory, and we can upgrade at our 
> leisure with newer information.
>
> But it is only a quibble - I wouldn't hold up any vote on this just 
> because of an idle bar prediction on consequences.

Point taken.  However, the rationale behind the SHOULD is that:

A) The ADs were slightly uncomfortable with only one MTI, though not
   adamantly opposed to it, and

B) People really should implement Curve448, so why not write the
   document in such a way as to encourage it?

So the SHOULD is a nice compromise between one MTI and two MTIs, where
sure we only have one MTI, but we've encouraged people who want a second
key exchange algorithm to converge on the same one.  This way down the
line, when Curve448 is widely supported in software, people will be more
likely to include it.

Make sense?

David