Subject: [TLS] DTLS record layer processing

From: Michael Tüxen <[email-masked]>
Date: Mon, 29 Jun 2009 16:49:44 +0200

Dear all,

when DTLS receives a packet is has to do input validation on
the version number and the length given in the record header
and the actual length of the UDP packet.

When should this be done and what should be the action taken
when the checks fail?

There is an implementation out, which considers a version
mismatch or a length given in the record layer which is
larger than allowed by the protocol a fatal error.
This might be OK for TLS, but I think is inacceptable for
DTLS. An attacker only needs to guess the UDP port numbers
and IP addresses and can craft a UDP packet with an illegal
record length field and the DTLS connection is gone.

Also
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-02.txt
states

    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 a
    bad_record_mac alert with level fatal and terminate its connection
    state.

If I understand things correctly, this means that as an attacker
I need only to send a UDP packet with a wrong MAC to perform
a DOS attack.

Am I wrong? Any suggestions?

Best regards
Michael

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2009 09:24:43 -0700

At Mon, 29 Jun 2009 16:49:44 +0200,
> When should this be done and what should be the action taken

It should discard the datagram.

> record length field and the DTLS connection is gone.

I agree, that that's not how implementations should behave.

> Am I wrong? Any suggestions?

I don't read the text that way. Rather, I think it says:

If you receive a packet with a bad MAC, you must either:

(a) Silently discard    [Preferred]
(b) Generate a bad_record_mac alert and terminate the connection.

What you must not do is generate any other alert and continue
the connection.

This was designed to avoid attacks where the attacker repeatedly
probed the victim implementation to see which error it generated.

-Ekr

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 30 Jun 2009 20:33:57 +0200

> It should discard the datagram.
Silently, I assume. Should this be specified somewhere?

http://www.ietf.org/rfc/rfc5246.txt says:

    record_overflow
       A TLSCiphertext record was received that had a length more than
       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
       with more than 2^14+1024 bytes.  This message is always fatal and
       should never be observed in communication between proper
       implementations (except when messages were corrupted in the
       network).

Maybe people use this TLS based procedure also for DTLS (like  
OpenSSL)...
> (b) Generate a bad_record_mac alert and terminate the connection.
I agree, but my point is:
If an implementation chooses (b), you can just send a malicious
packet and the connection is gone. Or am I missing something?
> What you must not do is generate any other alert and continue
Understood.
> probed the victim implementation to see which error it generated.
Understood, but I think (b) is bad in any case for DTLS. So why
not get rid of it and just require that implementation MUST
use (a), or at least SHOULD. At least for DTLS/UDP.

For DTLS/SCTP it is OK to send an alert since an attacker can
not insert packets because they are protected also with SCTP-AUTH.