Hi Brian, On 09/08/13 03:30, Brian Smith wrote: > Please see https://briansmith.org/browser-ciphersuites-01.html
.... > Suggestions for improvements are encouraged. Thanks for this. Here are my questions: * 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? * "We should avoid leaking the distinction between mobile and desktop products in the TLS handshake, which means that the handshake should look the same on mobile and desktop." Why is this a goal? There are many, many other ways of determining this distinction, some supported by Mozilla (e.g. the UserAgent string). This is not to deny that there are other reasons for having a consistent set, but this seems an odd one. The same question applies to your point about avoiding TLS fingerprinting. I think it should be a goal to make it hard to distinguish between specific instances of Firefox, but it seems to be not a goal to avoid people distinguishing between Firefox and IE, or Firefox for desktop and Firefox for Android. * "this proposal does not recommend supporting the CBC-HMAC-SHA-2-based ciphersuites that those browsers recently added" Can you spell out why? Is it because they don't offer forward secrecy? * "In the course of testing TLS 1.2 and the ALPN TLS extension, the Chromium team recently found that some servers choke when the ClientHello message in the TLS handshake is larger than 256 bytes." How many bytes are taken up per ciphersuite? How many can we probably fit in, if we say we need to include all the other stuff? * Re: Camellia and SEED: we should talk to the organisations which pushed for their addition, and our business development people in the region, before eliminating them. (This is not to say that we will definitely not remove them if they raise objections.) * "Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-384 are all more-or-less equal in terms of security given how they are used in TLS." However, if we never use them, then have to switch to them because a problem arises with HMAC-SHA-1, how will they have received any testing? More generally, is there a place for including ciphersuites 'of the future', perhaps at lower priority, to try and make sure there aren't problems or interop issues with them? * Your final section says what cipersuites should be added and dropped. Is this simply a config change with testing, or does it require code to be written in one or more of the TLS stacks? Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
