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