Re: [TLS] DTLS record layer processing

[Eric Rescorla <ekr at networkresonance.com>]

At Tue, 30 Jun 2009 20:33:57 +0200,
Michael Tüxen wrote:
> 
> 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)...

I agree that this is bad. I'll try to add a specific comment
to this effect in the document.


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

Agreed.


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

I could live with that, I think. What do other people in the WG
think?

-Ekr