[TLS] DTLS resilience [was: comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02]

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 23 October 2013 20:50 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A8421F9DFB for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 13:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HL4uUlXzsTe for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 13:50:20 -0700 (PDT)
Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3711E8252 for <tls@ietf.org>; Wed, 23 Oct 2013 13:50:18 -0700 (PDT)
Received: by mail-ee0-f52.google.com with SMTP id d51so665356eek.39 for <tls@ietf.org>; Wed, 23 Oct 2013 13:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=vkFoA8t+ryiiRiLcDUehgoa8PyT8TblbckdCqORUank=; b=XQaE207njQFU0TmLAEfz1NneAgYPc1t7DoLKmwJG8jjZkO85gFbdQlRZ8PyLFW8Tq8 EO8FQmMT3rLeWqgv33axj124DfiP9A9otWKiF6tZMEu/nIJSYE2cszOW8CdtDqD/Y2g+ VvZJhh6+vrpbU7UGQ+5mwYACXWKMbO8016rbcyUEHRFLWcrt/NJ7797K49AIH5D4xicv qj7sr42el5h3D2+qxiOCSuHafRX8wc/Yl/IZZ4afthSP9dv83nqa6nGiyCirj2SS4YIG RaW+Dx9RuQGjz0niHyYPeq/QD333Tn9wmZDKkXpNoIGI8axC6cRADUd4mKT081ucYI3P cczw==
X-Received: by 10.15.98.194 with SMTP id bj42mr4032620eeb.12.1382561415008; Wed, 23 Oct 2013 13:50:15 -0700 (PDT)
Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id r48sm74541933eev.14.2013.10.23.13.50.13 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 13:50:14 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <52683680.8020909@gnutls.org>
Date: Wed, 23 Oct 2013 22:50:08 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
References: <526797EE.2000206@gnutls.org> <CAL9PXLyguGgFtb9NqbkvrL82fV-Aj=HFJiex-Hu32xEec=9SLQ@mail.gmail.com> <5267E276.9050107@gnutls.org> <CABcZeBPGxc8qGOiB2sqk9vnh98=SiH6qvkriOLqdfe-xcxmDMA@mail.gmail.com> <5267FC0A.7040009@gnutls.org>
In-Reply-To: <5267FC0A.7040009@gnutls.org>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [TLS] DTLS resilience [was: comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Wed, 23 Oct 2013 20:50:21 -0000

On 10/23/2013 06:40 PM, Nikos Mavrogiannopoulos wrote:

>>     as a general comment I think DTLS' resilience on forged packets
>>     isn't that good. It makes it a perfect target to lay an attack. I think
>>     it would be much better to have a limit by default on the allowed
>>     packets with wrong MAC.
>> S 4.2.7 provides some guidance in this area, but it's pretty vague:
>>
>>    Note that Alert messages are not retransmitted at all, even when they
>>    occur in the context of a handshake.  However, a DTLS implementation
>>    which would ordinarily issue an alert SHOULD generate a new alert
>>    message if the offending record is received again (e.g., as a
>>    retransmitted handshake message).  Implementations SHOULD detect when
>>    a peer is persistently sending bad messages and terminate the local
>>    connection state after such misbehavior is detected.
>> It certainly seems like it would be a good thing to document some
>> better guidance about how many bad MACs you should tolerate.
>> Do you have any thoughts about what makes sense?
> 
> I was thinking of disabling wrong MAC tolerance completely if the
> underlying layer has checksums. UDP for example has checksums and
> packets that are altered due to transmission errors will be discarded
> anyway. In lower protocols such as ethernet we also have checksums.
> 
> If someone needs to transmit in raw without any checksums, he could
> exceptionally allow wrong MAC tolerance.

It seems I answered hastily. I think there is an issue with what I
proposed. I see 2 things that need to be ensured here.
1. The session must be resilient to accidental transmission errors.
2. The session must be resilient to termination by someone who hasn't
access on the communication line

Do I miss something else?

[I don't think there is point being resilient to someone with access to
the communication line, as he could always cause a DoS by simply
dropping all packets.]

My proposal above handles 1, but not 2. In the UDP case anybody can
forge a DTLS packet and send it on the server port claiming to be the
client (he doesn't need to know the client port, he just sends many
packets with all possible ports). DTLS will discard packets out of
epoch, or with old sequence numbers, but sequence numbers are easy to
guess in DTLS. They are sequential and start from 0. Thus one could
"easily" avoid the window check in DTLS and pass a packet with an
invalid MAC.

So if wrong MAC tolerance is removed in a future revision of DTLS, it
has to be combined with something that ensures (2). That could be random
sequence numbers (similar to TCP), or something else.

regards,
Nikos