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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 23 October 2013 14:58 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 D153B11E83B8 for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 07:58:58 -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=[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 03CTcc4r7dXO for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 07:58:58 -0700 (PDT)
Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5363E11E83AC for <tls@ietf.org>; Wed, 23 Oct 2013 07:58:54 -0700 (PDT)
Received: by mail-ee0-f46.google.com with SMTP id c1so455852eek.5 for <tls@ietf.org>; Wed, 23 Oct 2013 07:58:41 -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=7qJJQDQTF2oweDLuPiBvrkzgI1uds1tkFEFt8UKn8dk=; b=WBKee3kCYuZygmEYUYFLGKoco+H5wk5qzIDpVJOzMvSE9u9Fp/69zJgsLBZnnjlX6W ZZOP7bI6hcVbs+OhH6MTsw6nEsjFs8XeuY/4gCg110qYomDsICGJaFoOfvsc6cudzAoN Nvo5ughR4qW+HzAJEYdJ8u31WYgRh6tyCXdPlsiutLJ4xJGg7Kyew1M7oiq+eZnwbp2W 7+/ENSl/dErzufP2Vq1e8qioWjaPoT4NeruBGXdQhQmmIn1u4EkWXoNAmE15AHjCaNEl dR5a6FdVTYzEef7hg71qDJka6r/kxaOygPJfC4CIYIGANd7AEuNboDOLFHIv9PRBqkYu fgkA==
X-Received: by 10.15.53.132 with SMTP id r4mr2279875eew.5.1382540321410; Wed, 23 Oct 2013 07:58:41 -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 u46sm71063370eep.17.2013.10.23.07.58.40 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 <n.mavrogiannopoulos@gmail.com>
Message-ID: <5267E41B.4080504@gnutls.org>
Date: Wed, 23 Oct 2013 16:58:35 +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: Eric Rescorla <ekr@rtfm.com>
References: <526797EE.2000206@gnutls.org> <CABcZeBPEnaLGg8ncRKZCUYv0ETkwyim1qoK7qHTXbm7n-3vjVw@mail.gmail.com>
In-Reply-To: <CABcZeBPEnaLGg8ncRKZCUYv0ETkwyim1qoK7qHTXbm7n-3vjVw@mail.gmail.com>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>, =?ISO-8859-1?Q?Joachim_Str=F6mbergso?= =?ISO-8859-1?Q?n?= <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 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.

regards,
Nikos