Subject: Re: [Uta] Real draft-ietf-uta-tls-bcp Feedback

From: Kohei Kasamatsu <[email-masked]>
Date: Mon, 14 Jul 2014 10:50:40 +0900

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-masked]> 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-masked]
>>> <mailto:[email-masked]>> 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-masked]
> 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-masked]

---

From: Watson Ladd <[email-masked]>
Date: Sun, 13 Jul 2014 21:24:11 -0700

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.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Kohei Kasamatsu <[email-masked]>
Date: Mon, 14 Jul 2014 14:51:05 +0900

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

---

From: "Leif Johansson" <[email-masked]>
Date: Mon, 14 Jul 2014 10:11:08 +0200

> protected by encrypt-then-mac or AEAD in draft-ietf-uta-tls-attacks.

Could you suggest a couple of lines of text?

---

From: Kohei Kasamatsu <[email-masked]>
Date: Mon, 14 Jul 2014 18:08:51 +0900

> Could you suggest a couple of lines of text?

I understood that what you say is to show resource which explains AEAD
and encrypt-then-mac are countermeasure of lucky 13.

It is shown in Use Authenticated Encryption of section 7 in "Lucky
Thirteen: Breaking the TLS and DTLS Record Protocols" [1]

[1] http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

Best,
Kohei KASAMATSU

---

From: "Leif Johansson" <[email-masked]>
Date: Mon, 14 Jul 2014 13:30:25 +0200

No I was asimg you to suggest a concrete change to the draft - this helps the author move things along.

> 14 jul 2014 kl. 11:10 skrev "Kohei Kasamatsu" <[email-masked]>:
> 
>

---

From: Kohei Kasamatsu <[email-masked]>
Date: Mon, 14 Jul 2014 21:22:08 +0900

I am sorry for misunderstanding.

I would like to suggest an addtion of "The Lucky Thirteen attack can be
mitigated by using authenticated encryption like AES-GCM [RFC5288] and
encrypt-then-mac [I-D.ietf-tls-encrypt-then-mac] instead of
MAC-then-encrypt." into the end of section 2.3 in
draft-ietf-uta-tls-attacks-01.

Modified section 2.3 is as follow.

--
2.3.  Lucky Thirteen

   A consequence of the MAC-then-encrypt design in all current versions
   of TLS is the existence of padding oracle attacks [Padding-Oracle].
   A recent incarnation of these attacks is the Lucky Thirteen attack
   [CBC-Attack], a timing side-channel attack that allows the attacker
   to decrypt arbitrary ciphertext. The Lucky Thirteen attack can be
   mitigated by using authenticated encryption like AES-GCM [RFC5288]
   and encrypt-then-mac [I-D.ietf-tls-encrypt-then-mac] instead of
   MAC-then-encrypt.
--

[RFC5288]  Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
           Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
           August 2008.

[I-D.ietf-tls-encrypt-then-mac]  P. Gutmann, "Encrypt-then-MAC for TLS
and DTLS", draft-ietf-tls-encrypt-then-mac-02 (work in progress), June
2014.

Best,
Kohei KASAMATSU

-- 
Kohei KASAMATSU

NTT Software Corporation