Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02

Eric Rescorla <ekr@rtfm.com> Wed, 23 October 2013 15:44 UTC

Return-Path: <ekr@rtfm.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 89C6411E840D for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 08:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 iQPBqBD-fEh6 for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 08:43:54 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id D621011E83A2 for <tls@ietf.org>; Wed, 23 Oct 2013 08:43:10 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id l12so7589732wiv.3 for <tls@ietf.org>; Wed, 23 Oct 2013 08:43:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Px6GYLIWnL+h3OGCWVmWfSJq0wPoKzdp1WCCWr1g7tc=; b=Fz3BSDIs9ntsQKqEPvM2HDMawRlbvqBSLV3soQTxgnkx6/MGAH3EtEVgXvFjVm2rwj wwuzEgwJB8a9uwLB232r/A+haD7jtaNYKcSXkOJ0/XHxAqFexjaj1HyHhDIw7befsULw FUnu/2CRX5jGP/4tBpm09tdyCvaXYdVj1mEig79aMrlmAYpJthiOFcL+6ZRLZYpdT/bt NOggs/X17BqrpMQddERB4L9/9GlEicncLxfhPfvb5aASSYVAUbMHNeaKC/3/vTp+QM7X oHfb7uL0+JgZvfs8xJPIulkPrdqH15W1Mp7ypfeya6ZkdFxdC9bOkoC5rccpoLoB6fwc hBsQ==
X-Gm-Message-State: ALoCoQmy6VYKjq55LGjnIvL/iOF6HqZXN7jt2Ymo+p6TV5ktppk/W7Sssm2oDXmPic0l9tWWtoMS
X-Received: by 10.194.174.36 with SMTP id bp4mr2196827wjc.7.1382542990104; Wed, 23 Oct 2013 08:43:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Wed, 23 Oct 2013 08:42:30 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <5267E276.9050107@gnutls.org>
References: <526797EE.2000206@gnutls.org> <CAL9PXLyguGgFtb9NqbkvrL82fV-Aj=HFJiex-Hu32xEec=9SLQ@mail.gmail.com> <5267E276.9050107@gnutls.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 23 Oct 2013 08:42:30 -0700
Message-ID: <CABcZeBPGxc8qGOiB2sqk9vnh98=SiH6qvkriOLqdfe-xcxmDMA@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: multipart/alternative; boundary=089e0141a0aecff00404e96a5f3d
Cc: "tls@ietf.org" <tls@ietf.org>, =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= <joachim@secworks.se>
Subject: Re: [TLS] 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 15:44:02 -0000

On Wed, Oct 23, 2013 at 7:51 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org>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?

-Ekr