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. > * "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). > There is a difference between leaking to somebody on the network and leaking to the server you are connecting to. Remember that TLS hides the User-Agent string and other HTTP-level information is hidden from others on the network. So, if Firefox for Android and Firefox for Desktop use the exact same TLS handshaking logic/parameters, then it should be possible to make them indistinguishable from each other. > 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. > If every browser's TLS handshake were to look the same, then observers on the network wouldn't be able to tell browsers apart, though the website you are connecting to obviously would. I admit that is a state that is likely to be difficult to obtain. * "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? > It is explained below. Worse performance, no security benefit, and they take up space in the handshake. > * "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? > They take two bytes per ciphersuite. If the 256-byte limitation cannot be worked around, then we basically can't afford to waste *any* bytes in the TLS handshake. It is already likely going to be very difficult for us to support the ALPN extension as it is, even after making these reductions. > * 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.) > Do you have suggestions for who to contact? > * "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? > We will soon have AES-GCM and we'll hopefully soon have Salsa20/12+(Poly1305|UMAC|VMAC) to mitigate that. Relying on either/both of those alternatives kills more birds with fewer stones. I think ultimately we'd rather have all HMAC-based ciphersuites also marked deprecated, for performance and security reasons. > * 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? > Dropping ciphersuites is a simple configuration change. In the top table, the "notes" column lists the ciphersuites that will require code changes to NSS and to SChannel. Bug 880543<https://bugzilla.mozilla.org/show_bug.cgi?id=880543>tracks the addition of AES-GCM ciphersuites to NSS's libssl. OpenSSL already implements them. I think Google may be working on Sals20/12+Poly1305 ciphersuites and there has been some small progress on adding Sals20/12 ciphersuites in the IETF TLS working group. Reordering ciphersuites in SChannel can be done with a configuration change to the app. Reordering ciphersuites in NSS either requires us to reorder them for all apps, or to add an API to customize the order to libssl. I would prefer to change the order in NSS itself. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
