Re: [TLS] DTLS implementation attack?

[Martin Rex <[e-mail]>]

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.


-Martin