Re: [TLS] DTLS record layer processing

[Michael Tüxen <Michael.Tuexen at lurchi.franken.de>]

On Jun 30, 2009, at 6:24 PM, Eric Rescorla wrote:

> 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.
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)...
> > 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.
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
> the connection.
Understood.
> This was designed to avoid attacks where the attacker repeatedly
> 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.
> -Ekr