Re: [TLS] DTLS implementation attack?

[Eric Rescorla <[e-mail]>]

On Tue, Dec 6, 2011 at 10:27 AM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>>
>> On Tue, Dec 6, 2011 at 9:32 AM, Martin Rex <[e-mail]> wrote:
>> > Nikos Mavrogiannopoulos wrote:
>> >>
>> >> On Tue, Dec 6, 2011 at 5:56 PM, Marsh Ray <[e-mail]> wrote:
>> >>
>> >> > 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
>> >>
>> >> 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.
>> >
>> > 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).
>>
>> I'm not following why silent discard would create a problem. Can you explain
>> 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.

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