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

Nikos Mavrogiannopoulos <> Wed, 23 October 2013 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2872311E8452 for <>; Wed, 23 Oct 2013 09:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xHbtcAoZvOvk for <>; Wed, 23 Oct 2013 09:41:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::229]) by (Postfix) with ESMTP id 61CDE11E840E for <>; Wed, 23 Oct 2013 09:40:58 -0700 (PDT)
Received: by with SMTP id d49so532555eek.0 for <>; Wed, 23 Oct 2013 09:40:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=XhYv6f1snI0NFja0GVZg9rVpm8pngi5xX7h6CjgEsT0=; b=cO4HlbKMt1xyKrocU0PMXyG9pMtSd6tLb/F9ni4gzXKu+wBOQyfIw5ok1Lzp7Jzmc7 /nkEP2sf6jw4B7zGgPi60qVS06QLT3DaslHQBld+a1A8Dfk6Ybt6W0O5aLjAfcqaa5Um uRwI6k3CxnjGM3tJ26ig+OVvrxEcGeZdI8hea4t3HKecN2CrVpuvV/Ep16r05ld3zjeD k1/RRRdoXMrxLrI6R1Z9CNm4mDnwXDMzy/2/vUCb3FPVqx8cLBDy07aHe6D5Km28Yxkr DCVmJwdqIJHQs0HzWJPdmp3tzmyq2gGjYH5S4A2Z93v3QgU8dJsp5C3LiwR6aVlt6np7 A5pA==
X-Received: by with SMTP id z47mr2877792eep.24.1382546449098; Wed, 23 Oct 2013 09:40:49 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id h45sm72162914eeg.5.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 09:40:48 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Wed, 23 Oct 2013 18:40:42 +0200
From: Nikos Mavrogiannopoulos <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: "" <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Oct 2013 16:41:36 -0000

On 10/23/2013 05:42 PM, Eric Rescorla 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.