ianG <i...@iang.org> writes:
>Hmmm, I'd say that is 11 times longer than it needs to be :) Anything wrong
>with just this:
>
> CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_256_GCM_SHA384 =
> { 0x00, 0xXX }
The suites listed were based on a survey of what was used/supported
(admittedly, given that active use of ECC suites on the public Internet is
practically nonexistent, this was more of a "what can this implementation do"
rather than "what's being actively used"). So the suites were the common
subset that pretty much everything I could find supported. And that's the
point of the RFC, "here's a fixed subset which will (modulo odd implementation
bugs) guarantee interoperability if you use them".
>But when people come to help, they don't improve the protocol ... what they
>instead do is seek personal gratification in trivial replacement of
>algorithms. What they can't do is agree on a reasonable upgrade that takes
>care of the passage of time ("we know so much more today") with a new single
>suite, and instead compromise on rewarding everyone's ego with a little
>number somewhere.
That's pretty much exactly how these design-by-committee messes come about
(alongside groupthink and whatnot).
>It is therefore an additional hypothesis of mine that committees cannot do
>security protocols.
Yup. The ideal size for a security protocol design is about three people (to
ensure there's cross-checking). You can make it smaller if you can replace
the lost people with a lot of skill and talent (or if it's, say, a minor
tweak/obvious fix of some protocol rather than a completely new design), but
as you make it larger the committee crapification sets in.
Peter.
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
