On Fri, Jul 09, 2010 at 10:40:01AM -0700, Bill Sommerfeld wrote:
> I'm told that folks evaluating cryptographic protocols generally
> prefer to see suites of algorithms defined together rather than
> allowing the user to arbitrarily mix and match; this generally
> reduces the number of possibilities to evaluate and also eliminates
> silly combinations where one algorithm is much weaker than the
> other.
It... depends.
For example, SSHv2 negotiates various algorithms separately and
concurrently:
- key exchange
- server host authentication
- data encryption
- data authentication
- compression (not of cryptographic interest)
TLS on the other hand has pre-assigned/registered cipher suite
identifiers that combine all of the above (except compression).
Assigning a cipher suite ID to every possibly desirable combination of
algorithms could mean having a very large number of cipher suites. In
practice this is not a problem because a fairly small number of cipher
suites will satisfy most users' needs[*].
I don't recall any sufficiently strong arguments that the SSHv2 approach
was cryptographically weak (evidence: SSHv2 progressed after all).
However, I endorse the TLS approach over the SSHv2 approach, provided
one does not paint oneself into a corner that ultimately leads to a
cipher suite explosion. In the case of IPS I don't see the i-team
painting themselves into such a corner.
Nico
[*] Cipher suite explosions can still happen though. Imagine, as a very
contrived example, adding GSS-API support to TLS similar to how it
was done in SSHv2: first, a fully anologous design wouldn't be
possible since the set of GSS-API mechanisms is open, second we
could easily multiply the number of cipher suites by 2 or much more,
depending on protocol design choices. This is a very contrived
example because we'd NOT extend TLS in the same way as we did for
SSHv2. Heck, attempts to extend TLS to support GSS-API for
authentication have foundered on the round-trip impedance mismatch
between the two.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
