Re: [TLS] DTLS record layer processing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] DTLS record layer processing



At Mon, 29 Jun 2009 16:49:44 +0200,
Michael Tüxen wrote:
> 
> 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?

It should discard the datagram.


> 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.

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


> 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?

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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.