Re: [TLS] DTLS record layer processing
Eric Rescorla <ekr@networkresonance.com> Thu, 02 July 2009 03:57 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 C111D3A68F5 for <tls@core3.amsl.com>; Wed, 1 Jul 2009 20:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.104
X-Spam-Level:
X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=-0.422, 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 Bvc++1VlZHmA for <tls@core3.amsl.com>; Wed, 1 Jul 2009 20:57:30 -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 CD7223A68C5 for <tls@ietf.org>; Wed, 1 Jul 2009 20:57:30 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 2A7601C61F9; Wed, 1 Jul 2009 20:58:09 -0700 (PDT)
Date: Wed, 01 Jul 2009 20:58:09 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <E7927ECD-3437-4A08-9CF6-62DF74030B95@lurchi.franken.de>
References: <C80DFD9E-9192-46CF-A1F0-C890DF53B2FF@lurchi.franken.de> <20090630162443.D51561C5ED3@kilo.networkresonance.com> <E7927ECD-3437-4A08-9CF6-62DF74030B95@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: <20090702035809.2A7601C61F9@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: Thu, 02 Jul 2009 03:57:31 -0000
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
- [TLS] DTLS record layer processing Michael Tüxen
- Re: [TLS] DTLS record layer processing Eric Rescorla
- Re: [TLS] DTLS record layer processing Michael Tüxen
- Re: [TLS] DTLS record layer processing Eric Rescorla