On 27 May 2014 15:36, Yaron Sheffer <[email protected]> wrote: > I will need an explanation on why Lucky13 is "an implementation error". > Looks like a protocol error to me.
Lucky 13 is an attack on CBC padding, where you have an oracle about whether or not the padding is valid and you use that to perform decryptions. The specific oracle Lucky 13 uses is a timing attack - if it takes more time, it's valid if it takes less time, it's not. If the implementation is constant time, like it's supposed to be, then there's no oracle, and no attack. https://www.imperialviolet.org/2013/02/04/luckythirteen.html is a good reference. > Re: upcoming technologies (TACK, CT), I suggest to not even mention them in > this document. It is not a survey of TLS technologies but a guide for the > perplexed deployer (and possibly their vendor). When these things become > "current" practices, we will need to republish. I agree with this. > OCSP (stapling or otherwise) assumes widespread deployment of OCSP servers. > Is that the situation today? To put it into concrete terms, are more than > 25% of currently issued certificates provided with a working OCSP endpoint? Yes. http://uptime.netcraft.com/perf/reports/performance/OCSP >> On Tue, May 27, 2014 at 1:43 PM, Benjamin Black <[email protected] >> <mailto:[email protected]>> wrote: >> >> Even if OCSP endpoints are prevalent, do many browsers check and is >> that even the right model? Thoughtful practitioners suggest not: >> https://www.imperialviolet.org/2014/04/19/revchecking.html OCSP Stapling neatly solves a lot of problems of revocation. It has no side channels, it handles CA downtime for several hours while having a vulnerable window measurd in hours and not days, and so on. And with a must-staple pinning for sites in the HSTS header (which I hope will be coming 'real soon now'), it becomes hard fail. And, I have a small hope that we can get enough of the deployed internet to stapling over the next several years, so that hard fail becomes a possibility. -tom _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
