Re: Proposal: Disable SSLv3 in Firefox ESR 31
On Wednesday 22 October 2014 15:54:57 Julien Pierre wrote: Hubert, On 10/22/2014 05:27, Hubert Kario wrote: Problem is that if something doesn't work in one browser and does in another users blame the browser. Even if the browser that doesn't work does the right thing. What if all browsers started doing the right thing ? That's a very hypothetical question... What if all servers deployed TLS1.2 and refused connections with anything older? That would also fix the problem... Recommending the use of obsolete browsers is also a bad idea - they have well known vulnerabilities. It also may simply be not possible in walled gardens (phones/tablets). Are there phone/tablets which can't install any 3rd party browsers at all ? AFAIK, iOS devices require you to use the system TLS stack. Anyway, the very fallback we are talking about here is a known vulnerability. It sounds like we want a browser that is current on vulnerability fixes, except for this one. I'm not saying it isn't. But it is behaviour that is expected by users. Just like users expect to not see this connection is untrusted, you may be subject to MITM attack when connecting over plain HTTP. This way, browsers won't subject the requests to 99.999% of servers that are not TLS-intolerant to needless MITM attacks, not to mention extra network bandwidth and round trips. It's closer to below 99% or 89%, depending on which TLS version you look at. Do you have any pointer to the versions and data for this 99% / 89% ? http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Fwd: Time to dump NSS
Forwarding to dev-tech-crypto where this is more on-topic. -Dan Veditz ---BeginMessage--- NSS was designed when physically distributed smart cards were anticipated to become the norm. This didn't really happen but instead we got mobile devices with support for TEEs (Trusted Execution Environments): http://webpki.org/papers/SKS-KeyGen2_FullStack.pdf NSS cannot deal with provisioning of TEEs because it doesn't support provisioning of keys in an E2ES (End-To-End-Security) fashion. This is hardly surprising since keygen was designed 1995. In addition we need entirely new key access protection models: http://webpki.org/papers/key-access.pdf With a new key-system you could do things like: https://mobilepki.org/WebCryptoPlusPlus There's much more to this but I wanted to hear what Mozilla are thinking regarding key-storage. I'm prepared to help making this upgrade possible! Cheers, Anders Rundgren ___ dev-security mailing list dev-secur...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ---End Message--- -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: Disable SSLv3 in Firefox ESR 31
Hubert, On 10/23/2014 07:53, Hubert Kario wrote: Are there phone/tablets which can't install any 3rd party browsers at all ? AFAIK, iOS devices require you to use the system TLS stack. I see, I didn't know. But it still would seem that any second connection (fallback) would be dictated by the browser implementation itself, and not the stack. Anyway, the very fallback we are talking about here is a known vulnerability. It sounds like we want a browser that is current on vulnerability fixes, except for this one. I'm not saying it isn't. But it is behaviour that is expected by users. I think most users are woefully unaware of any TLS connection retry / fallback being done by the browser. I think you meant to say that users expect the browser to continue to work with all their legacy TLS-intolerant devices somehow. That doesn't mean that a legacy mode of operation in the browser wouldn't be an acceptable solution to them. Do you have any pointer to the versions and data for this 99% / 89% ? http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf Thank you. The 11% of TLS 1.3 intolerant servers is scary indeed. Do we have any idea which SSL stacks / server vendors are affected ? Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fwd: Time to dump NSS
Your subject, time to dump NSS, intimately affects NSS developers who will have to worry about replacing all the things NSS does for us before they can even start to think about the additional concepts. If you're proposing a mechanism that can live on the side without actually dumping NSS then I suppose we can discuss it elsewhere, but if it involves cryptography (how could it not?) then the tech.crypto group is the one the people who know about cryptography participate in. There are several (sometimes competing) efforts within the W3 and IETF to create standards around concepts like key management. We're unlikely to implement a solution that doesn't get buy-in from other browser and server makers in that kind of forum. -Dan Veditz -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
