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

Eric Rescorla <> Wed, 23 October 2013 10:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0685311E8360 for <>; Wed, 23 Oct 2013 03:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xwG+NOkae-+e for <>; Wed, 23 Oct 2013 03:50:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BF10F11E819A for <>; Wed, 23 Oct 2013 03:50:26 -0700 (PDT)
Received: by with SMTP id u57so607404wes.1 for <>; Wed, 23 Oct 2013 03:50:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vYPlzCEG2PS44JvgwFTlOrY39qgVACBWVcPoqr3dQa0=; b=e1WTk7K7yktA8pW6t7MgQ0Stgs6dXZQQAwD7Y758v0uvxSr6Ug/a+z/8ognTsfvTG/ En8n8ljcXur4J097pEgRT+uS26u0RpER0kLbUKbt125IYtSAGi1fnfwrS4ixcdzmJi1L O0wvfHzZY5bm5VD6OiSNR60GJPyrowcfRbzZkmM11tohUPB1dAtPJW3KzCpZ2/TCGfbW 3PisTDNeaf4Ti5DGs7MrWxcpI9jRAbCxyA8JQo1iHWP0V5OrlSyUBAU6FTS5vLkZmPvI LqnhqhZkvizjOGN9/IHSRxaDpMUjgIFLBry1h5uzsALtQl6cfq1wiT4oyt4cGQNaSyC2 xVkw==
X-Gm-Message-State: ALoCoQktm5pj8CLEVZ6hWNJNTXvvBx+vE+LyhyMQMfZjpOCB7+4XKDc3f5k6RwCpIcrI4oO0eeHH
X-Received: by with SMTP id w5mr1549834wif.8.1382525425948; Wed, 23 Oct 2013 03:50:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 23 Oct 2013 03:49:45 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Wed, 23 Oct 2013 03:49:45 -0700
Message-ID: <>
To: Nikos Mavrogiannopoulos <>
Content-Type: multipart/alternative; boundary="f46d044286e2e8358004e9664899"
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 10:50:33 -0000

On Wed, Oct 23, 2013 at 2:33 AM, Nikos Mavrogiannopoulos <>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:

   Each AEAD cipher suite MUST specify how the nonce supplied to the
   AEAD operation is constructed, and what is the length of the
   GenericAEADCipher.nonce_explicit part.  In many cases, it is
   appropriate to use the partially implicit nonce technique described
   in Section 3.2.1 of [AEAD]; with record_iv_length being the length of
   the explicit part.  In this case, the implicit part SHOULD be derived
   from key_block as client_write_iv and server_write_iv (as described
   in Section 6.3), and the explicit part is included in

With that said, the argument for having an explicit IV is as follows: it's
desirable to have a cryptographic AEAD primitive which doesn't
accidentally enable nonce reuse. In order to do this, you need to
internally generate the nonce, which means it must be explicit.
(For FIPS purposes, this means it must be generated inside the crypto
boundary). That's why the GCM algorithms were done this way.

You may or may not subscribe to this, but it's basically
an orthogonal question to the rest of these issues.