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

Nikos Mavrogiannopoulos <> Wed, 23 October 2013 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E017211E83BE for <>; Wed, 23 Oct 2013 07:51:41 -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 fRm8yZM9sySL for <>; Wed, 23 Oct 2013 07:51:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::22b]) by (Postfix) with ESMTP id B71D211E8217 for <>; Wed, 23 Oct 2013 07:51:40 -0700 (PDT)
Received: by with SMTP id e52so574640eek.30 for <>; Wed, 23 Oct 2013 07:51:40 -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=EcqeZNUe1WK55oF4HF7DCLXOxn7gBXoEXN55GpHQMok=; b=fLfI39yQx0J0Bt22EPyzBVaYoc2jxCdhoa8jkzQVQ4SyaZ8HTWRYpX1/vGGOE25o5v GmmvKYGFQAWie8eCU8/Fm8XJKDQ5RJP18jobnnZCujysAKudblxzluZXxTSHscQnxuEn +jVP0ILoLYwecOwZJbtfPPe2F0GCd/nSjSmQr3XHK/8GjutNKXzWwlFfB8uPexabP/nd 2+NBBb56tZZM9us768k+o2rniOePwFVssQ7dd54XAPWf+n/Z673r14vGxgnT3iH8cybP 1fFVRl4bQpYSZPUPU2avCeiqcaUUN/jmov5Mq0cbZv/t1JaAu8HnStgXmiZ+J4g91gcp ai/g==
X-Received: by with SMTP id bk48mr2326503eeb.22.1382539899947; Wed, 23 Oct 2013 07:51:39 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f49sm71017753eec.7.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 07:51:39 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Wed, 23 Oct 2013 16:51:34 +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: Adam Langley <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "" <>, Joachim Strömbergson <>
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 14:51:42 -0000

On 10/23/2013 03:55 PM, Adam Langley wrote:

>> * Applicability to Datagram TLS
>> The draft-agl-tls-chacha20poly1305-02 is only applicable to TLS and not
>> DTLS. That is because its combination with poly1305-chacha results to an
>> RC4-like effect where rearranged or lost packets result in a
>> desynchronization of the peers. draft-josefsson-salsa20-tls-02 applies
>> to both TLS and DTLS (this results from the choice of having the block
>> cipher AES in UMAC-AES). Having a stream cipher in DTLS was a main
>> reason (for me at least) for draft-josefsson-salsa20-tls-02.
> I don't believe that this is correct. There is no state carried
> between encryptions of records. Given the sequence numbers of a set of
> records, they can be processed in any order.
> Although the ChaCha draft doesn't mention DTLS, I don't think there's
> any fundamental difference here.

As far as I understand you use chacha to generate the keystream for
poly1305. Thus you carry state between records (chacha is a stream
cipher). I don't know if I have missed anything there, but I don't see
resetting chacha with a new IV per MAC calculation.

>> While I understand that there is quite some argumentation for using the
>> AEAD mode in TLS for every cipher/mac combination I don't find it
>> particularly convincing. In this specific case the AEAD mode adds 8
>> bytes of explicit nonce to the TLS record packet without providing any
>> clear advantages compared to the original stream cipher interface.
> This is incorrect, there is no explicit nonce in the ChaCha AEAD construction.

I missed that. Indeed.

> On the other hand, EtA allows for faster forgery rejection which,
> while not so useful for TLS, is useful for DTLS.

Is that really an issue? If yes, then EtA isn't also invulnerable to a
DoS attack, it is a big more lightweight.

However, 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.

> In any case, I don't believe that the security bounds laid out in the
> original Poly1305 paper[2] have been altered and I believe those
> bounds are sufficient for all users of (D)TLS.

Of course, these attacks require another flaw or leak to be practical.
However, my point is, that even with that additional flaw or
information, they will still not be applicable in AtE mode.