On 08/09/2013 10:12 AM, Brian Smith wrote:
On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham <g...@mozilla.org> wrote:* Can you provide some background or references on exactly how ciphersuite construction and choice works? Can I invent e.g. TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of elements? Can any combination be encoded in the ClientHello? Does the server support specific sets, or will it support my combination if it supports all the component pieces?No, each combination is hard-coded into its own distinct code point that is registered with IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4. This is a design choice based on the fact that many crypto modules don't let you mix/match algorithms at will, and because you often can't/shouldn't move keys between crypto modules.
Minor tweak. The design point has nothing to do with crypto modules. It had to do with analyzing combinations of algorithms. In 1994/5 when SSL-3 was being designed there were 2 camps: 1) select Asymmetric/Symmetric/Macing algorithms separately and 2) cipher suites. The security argument fell to cipher suites under the theory that it simplified your analysis of whether the algorithm is secure or not. At the time no one was thinking of doing operations in tokens, even at this point in time, I know of no crypto modules that actually implement cipher suites as a suite.
That info is really only of historical interest and doesn't affect the rest of Brian's argument (particularly since he's correct in the only part of the paragraph Gerv cares about --- that SSL uses suites, not arbitrarily mixed combinations of algorithms).
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
