Subject: [TLS] DTLS implementation attack?

From: Marsh Ray <[email-masked]>
Date: Tue, 06 Dec 2011 10:56:51 -0600

Anyone have more info on this?

Even just a CVE or 'fixed in' version would be helpful.

http://www.isoc.org/isoc/conferences/ndss/12/program.shtml#1a
> Plaintext-Recovery Attacks Against Datagram TLS
>
> Kenneth Paterson and Nadhem Alfardan We describe an efficient and
> full plaintext recovery attack against the OpenSSL implementation of
> DTLS, and an efficient, partial plaintext recovery attack against the
> GnuTLS implementation of DTLS. We discuss the reasons why these
> implementations are insecure, drawing lessons for secure protocol
> design and implementation in general.

Thanks,

- Marsh

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 6 Dec 2011 18:19:39 +0100

>> Plaintext-Recovery Attacks Against Datagram TLS

Concerning gnutls the 3.0.8 release reduces the timing information
revealed to an adversary to counter this attack. However, I'm still in
contact with the authors for more information on the issue.

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 18:32:59 +0100 (MET)

> contact with the authors for more information on the issue.

By following the "SHOULD silently discard" recommendation in DTLS
  http://tools.ietf.org/html/rfc4347#page-9

   In general, DTLS implementations SHOULD silently discard data with
   bad MACs.  If a DTLS implementation chooses to generate an alert when
   it receives a message with an invalid MAC, it MUST generate
   bad_record_mac alert with level fatal and terminate its connection
   state.

in combination with a CBC-block cipher with explicit initial IV,
you might be creating a decryption oracle, vaguely similar to the
design defect in XML encryption with block ciphers in CBC-mode
(XML encryption has an explicit IV, but no MAC at all -- which
is suicidal in online scenarios, such as WS-Security).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 6 Dec 2011 09:38:39 -0800

> is suicidal in online scenarios, such as WS-Security).

I'm not following why silent discard would create a problem. Can you explain
the threat you are concerned about?

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 19:27:51 +0100 (MET)

> the threat you are concerned about?

Nikos mentioned "timing information revealed to an adversary".

Plaintext guessing attacks for block ciphers in CBC-mode exploit
timing differences for padding errors and MAC-errors (a variation
of Vaudenay).

I know very little about DTLS.  Quickly glancing over the spec.
The last paragraph of this
   http://tools.ietf.org/html/rfc4347#section-4.1.2.5

"MUST discard" sounds even more dangerous.

How about replaying in a 1:1 interleave crafted records
trying to determine timing differences and the client's Finished
message, so that the latter will cause the server to resend the
server finished message -- which may enable the attacker to measure
differences in processing the crafted record.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 6 Dec 2011 10:51:53 -0800

> differences in processing the crafted record.

I'm still not sure I understand the threat model you have in mind
here.

These attacks rely on the attacker using the peer as an oracle to
learn something he doesn't otherwise know. In the case of the
Vaudenay attacks, assuming I remember correctly, it's whether
a block is correctly CBC padded versus whether it's incorrectly
CBC padded (and hence will produce an invalid MAC). So, what's
important here is to treat CBC padding errors the same way
you treat MAC errors.

As far as I know, treating MAC errors differently from valid packets
doesn't leak useful information, since tampering with anything in the
TLS packet should produce an invalid MAC, a fact the attacker is
presumably aware of.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 07 Dec 2011 10:46:15 +0100

On 12/06/2011 06:32 PM, Martin Rex wrote:
>>> Anyone have more info on this? Even just a CVE or 'fixed in'
>>> version would be helpful. 
>> revealed to an adversary to counter this attack. However, I'm still
>> in contact with the authors for more information on the issue.
> 
> http://tools.ietf.org/html/rfc4347#page-9 in combination with a
> CBC-block cipher with explicit initial IV, you might be creating a
> decryption oracle,

The attack on the paper was trying to detect the difference
in processing time of a message with an invalid pad and a message
with an invalid mac in CBC ciphers. For that they transferred a series
of packets followed by a heartbeat message[0], and then checked the
time it took for the heartbeat reply to arrive.

I don't want to copy their claims before it is published but they don't
mention that silently discarding messages is an issue, they rather say
that developers relied on that to make non constant time processing.

[0]. In gnutls that doesn't have the heartbeat extension they used a
custom technique of similar nature.

regards,
Nikos