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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D153B11E83B8 for <>; Wed, 23 Oct 2013 07:58:58 -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 03CTcc4r7dXO for <>; Wed, 23 Oct 2013 07:58:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::22e]) by (Postfix) with ESMTP id 5363E11E83AC for <>; Wed, 23 Oct 2013 07:58:54 -0700 (PDT)
Received: by with SMTP id c1so455852eek.5 for <>; Wed, 23 Oct 2013 07:58:41 -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=7qJJQDQTF2oweDLuPiBvrkzgI1uds1tkFEFt8UKn8dk=; b=WBKee3kCYuZygmEYUYFLGKoco+H5wk5qzIDpVJOzMvSE9u9Fp/69zJgsLBZnnjlX6W ZZOP7bI6hcVbs+OhH6MTsw6nEsjFs8XeuY/4gCg110qYomDsICGJaFoOfvsc6cudzAoN Nvo5ughR4qW+HzAJEYdJ8u31WYgRh6tyCXdPlsiutLJ4xJGg7Kyew1M7oiq+eZnwbp2W 7+/ENSl/dErzufP2Vq1e8qioWjaPoT4NeruBGXdQhQmmIn1u4EkWXoNAmE15AHjCaNEl dR5a6FdVTYzEef7hg71qDJka6r/kxaOygPJfC4CIYIGANd7AEuNboDOLFHIv9PRBqkYu fgkA==
X-Received: by with SMTP id r4mr2279875eew.5.1382540321410; Wed, 23 Oct 2013 07:58:41 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id u46sm71063370eep.17.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 07:58:40 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Wed, 23 Oct 2013 16:58:35 +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: Eric Rescorla <>
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
Cc: "" <>, Joachim Strömbergso n <>
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:58:58 -0000

On 10/23/2013 12:49 PM, Eric Rescorla wrote:

>     * Adding a new cipher in stream or AEAD mode?
>     The draft-josefsson-salsa20-tls-02 draft adds a new cipher to existing
>     implementations and can be combined with the existing MAC algorithms in
>     TLS (i.e., HMAC-SHA1). That is not the case in the
>     draft-agl-tls-chacha20poly1305-02 draft, where a single combination is
>     registered (of chacha with poly1305). Adding additional combinations in
>     the latter draft would require defining more AEAD modes, something that
>     could be a significant barrier that prevents its implementation (in
>     contrast with just replacing a cipher in the stream setting of TLS).
>     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.
> I don't believe that this is correct. That is how the GCM cipher suites
> are constructed, but it isn't required by RFC 5246, which says:

Indeed, and it seems the chacha draft didn't use the explicit IV anyway,
so I wasn't correct here. So I only don't get what is the advantage of
that mode. The stream interface of TLS is easier to extend with new
cipher/mac combinations without having to define again or differently
the details of a new AEAD mode (TLS stream mode defines how
authenticated-encryption is performed anyway, and there are no known
issues with that).

Thus from an implementer point of view I find the usage of the stream
mode the natural thing to do, unless something very special needs to be
done, or the cipher/mac combination is so tightly combined like GCM that
warrants the usage of the AEAD interface.