I'm sorry: unless you've written Lucky 13 proof code you shouldn't say it's an implementation error. Implementing the old TLS ciphersuites in a constant time manner took AGL 500 lines of C. It's a herculean effort, one that could be avoided by reversing the order of encryption and macing in TLS.
Standards developers should understand what can and cannot be implemented, and avoid making implementations gratuitously hard. On Sun, Jul 13, 2014 at 6:50 PM, Kohei Kasamatsu <[email protected]> wrote: > 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 -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
