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

Adam Langley <agl@google.com> Wed, 23 October 2013 13:56 UTC

Return-Path: <agl@google.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 A5FC611E838B for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 06:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 W4apVawg8aVO for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 06:56:05 -0700 (PDT)
Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73C11E8371 for <tls@ietf.org>; Wed, 23 Oct 2013 06:56:04 -0700 (PDT)
Received: by mail-vb0-f54.google.com with SMTP id q12so465446vbe.27 for <tls@ietf.org>; Wed, 23 Oct 2013 06:56:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QwbuHmA+74k2OLipps3krNBtYE1pyYEx0NT4Vhj84z8=; b=VEj4Vp5EAA+pY17rq/2W8+On7hbLQKJUcUFXVBDh6eRMcmkwB+axS/83m3uGPOaJlx 9HYKMtZtWuD3Uvg8js8YrffTobTQa+3u6OSSPLkiPZLrbsFx7UGbyCb/rPwAU4gXRpVU kpEOJjgzliNkGWiD+xyMQs3d0CJ2f97495Rx7TnZHm0WdepuuJlFzEQbkU9lci5IVQyx zK3P4Bz113pRnviq9ZEaoCn+VKMvGgo5r9LjiXyKno6Qgb7vuqjFHzoENdU5lzck3ZMJ 2rQGGNdjkVFT4VhpJDTiR01vJY11+rTkq+iJ31UPzUa2NIDsbVs9eJ2Q8yk/qSw2OPW6 RNdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QwbuHmA+74k2OLipps3krNBtYE1pyYEx0NT4Vhj84z8=; b=UpqNvEfmxmPixw9sri6p70N7x7YYORhXFtSzBKbExq9bYmG92gZdV9mkUNb+Z7JYKI 8NedEI6iOnbL2K3QPoopi3q3psY95U9V71pDWdOMRhIGCedt4GAbFNrEhfmuXgLSBDjq /Ie3V8vwe+VKtDbI6NZ3b6jX9y/wQzE3QsaYnbBwaILY/Ss5lGc8ro8rtl8ttvsCMOt3 E5+2Cs822nWoqvaB3oiLCJEgasUZB4cu4jEwJZan3nMz/JKwxMJLY7pB5WEuBAh92Oyw KA6bgVjUugrmgxBY5xP1op3vF4rsN91KtuzmO3hx09WG6wvqVxMEpAn1vBVf6KLmqyMG Y39A==
X-Gm-Message-State: ALoCoQmKM5e+rlxJCzRk8/oVFW9kLZzpuLbB3eh0TdOyhRJAg5SIbh2L6ccfMl19O+BLcR3X2AHYthlT+BSDJD3/TKTa1pT0hFcsUn/098wYw3iEdFSKZqUYaJ63jUOjhmU1j75AUeyScNfB4MzjpL9vVovbed9hs5ves0B1Y9cPFtl/B6Oy8PUhDeDXy/Glp0x2HkQzWQnj
X-Received: by 10.58.146.71 with SMTP id ta7mr1214689veb.23.1382536564053; Wed, 23 Oct 2013 06:56:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Wed, 23 Oct 2013 06:55:42 -0700 (PDT)
In-Reply-To: <526797EE.2000206@gnutls.org>
References: <526797EE.2000206@gnutls.org>
From: Adam Langley <agl@google.com>
Date: Wed, 23 Oct 2013 09:55:42 -0400
Message-ID: <CAL9PXLyguGgFtb9NqbkvrL82fV-Aj=HFJiex-Hu32xEec=9SLQ@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>, =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= <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 13:56:05 -0000

On Wed, Oct 23, 2013 at 5:33 AM, Nikos Mavrogiannopoulos
<nmav@gnutls.org>; wrote:
> Nevertheless, even if draft-agl-tls-chacha20poly1305-02 could be made
> efficient in hardware, in our opinion the performance benefits don't
> justify switching from a winner of an international competition to
> another algorithm (even if it is a derivative of it).

I don't think that there's much between them, but have a slight
preference for ChaCha, which mirrors the CFRG: "The RG expressed a
preference for ChaCha." [1]

[1] http://www.ietf.org/mail-archive/web/tls/current/msg10221.html

> * 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.

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

Chrome is conducting experiments at the moment to test the
transparency of the general Internet to TLS 1.0 and 1.2, although it
will take a few months for the results. If TLS 1.2 turns out to be
non-viable then I agree that some changes will be needed somewhere,
but I'm still awaiting that data.

> Both drafts introduce a universal hash based MAC. However, the
> chacha-poly1305 draft uses the encrypt-then-authenticate (EtA)
> construction while the salsa20 draft uses TLS' authenticate-then-encrypt
> (AtE) construction. When combined with ideal ciphers and MAC algorithms
> both modes can be equivalent. However, the AtE construction has the
> advantage of not revealing the MAC nor the authenticated data to an
> adversary. Interestingly enough the only known attacks on universal hash
> based MACs require access to MAC and data [1]. That is, these attacks
> (the key guessing and the divide and conquer) do not directly apply to
> draft-josefsson-salsa20-tls-02.
>
> Of course these attacks are of high complexity and impractical (unless
> some other weakness in the TLS protocol, or the MAC algorithm is found),
> but they nevertheless reinforce the view that the AtE construction has
> advantages on non-ideal MAC algorithms.

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

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.

[2] http://cr.yp.to/mac/poly1305-20050329.pdf


Cheers

AGL