Re: [TLS] DTLS record layer processing

Eric Rescorla <ekr@networkresonance.com> Tue, 30 June 2009 16:24 UTC

Return-Path: <ekr@networkresonance.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD2A28C3CC for <tls@core3.amsl.com>; Tue, 30 Jun 2009 09:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.192
X-Spam-Level:
X-Spam-Status: No, score=-0.192 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u1npEl+MHhF for <tls@core3.amsl.com>; Tue, 30 Jun 2009 09:24:54 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 50EB03A6A3E for <tls@ietf.org>; Tue, 30 Jun 2009 09:24:45 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D51561C5ED3; Tue, 30 Jun 2009 09:24:43 -0700 (PDT)
Date: Tue, 30 Jun 2009 09:24:43 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <C80DFD9E-9192-46CF-A1F0-C890DF53B2FF@lurchi.franken.de>
References: <C80DFD9E-9192-46CF-A1F0-C890DF53B2FF@lurchi.franken.de>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20090630162443.D51561C5ED3@kilo.networkresonance.com>
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS record layer processing
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:24:56 -0000

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