Dear Watson Ladd,
I don't intend to say that it is an implementation error. I think that RFC should specify API and input-to-output correspondence for interoperability and do not need to specify countermeasure of side channel attack and implementers choose the countermeasure. (Provably, it is careless opinions becauseas hardness of countermeasure depends on attack as you pointed out and there may be attack whose countermeasure should be specified in RFC. I am sorry.) But draft-ietf-uta-tls-bcp-01 uses AEAD as the countermeasure of Lucky 13. So I think that it is kind to write the fact that Lucky 13 can be protected by encrypt-then-mac or AEAD in draft-ietf-uta-tls-attacks. sincerely, Kohei KASAMATSU (2014/07/14 13:24), Watson Ladd wrote: > 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 > > > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
