On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco <cvie...@mozilla.com> wrote:
> Hello Brian > > I think this proposal has 3 sections. > 1. Unifing SSL behavior on browsers. > 2. Altering the criteria for cipher suite selection in Firefox (actually > NSS) > 3. removing certain cipher suites from the default firefox ciphersuite. > > On 2: > The proposal is not clear. I want an algorithmic definition. <snip> This criteria gets to your ordering proposal. What do you think of > re-framing your list in a criteria like this? (note national ciphers could go in step 6 instead of step 3). > That sounds reasonable to me. I did not invest too much effort on making the results computable from the rationale section because I think it is likely that a lot (or all) of the rationale section would be reduced or removed from any IETF internet draft that proposed a web browser profile of TLS. > On 3: > > Not adding: > TLS_(EC?)DHE_RSA_WITH_AES_(**128|256)_CBC_SHA256 > Disagree I dont think a potential performance issue should prevent us from > deploying that suite as there could be sha1 attacks that we dont know of. Now that NSS has AES-GCM, we have an alternative to HMAC-SHA1. Also, if we are a little presumptuous, we can expect to have a third alternative in Salsa20/12+(UMAC|VMAC|Poly1305) sometime in the near future. If we find it is important to offer HMAC-SHA256/384 later, we can do so then. But, if we add them now, we will have difficulty removing them later. > If we have enough space in the handshake I see no problem in including > them. > We will have to determine whether the 256-byte client hello limitation is really something that we have to deal with in the long term. But, even if that turns out now to be something we need to ever worry about, I would still be against adding HMAC-SHA256/384 when there seem to be better alternatives that do not regress performance from what we're offering now. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
