Dear Tom Ritter, Yaron Sheffer,
>> 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. Basically, I also think that side channel attacks (like timing attack) should be protected by countermeasure of implementation. However, I think that it is valuable to write the fact that Lucky 13 can be protected by encrypt-then-mac or AEAD in draft-ietf-uta-tls-attacks. Actually, draft-ietf-uta-tls-bcp-01 adopted AEAD as the countermeasure of Lucky 13. Best regards, Kohei KASAMATSU (2014/05/28 11:31), Tom Ritter wrote: > 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 > -- Kohei KASAMATSU NTT Software Corporation TEL: +81 45 212 7908 FAX: +81 45 212 9800 E-mail: [email protected] _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
