Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)

Brian Smith <brian@briansmith.org> Sat, 07 December 2013 03:44 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0411AE1D0 for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 19:44:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-gyXANKbbbF for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 19:44:34 -0800 (PST)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBFE1AE017 for <tls@ietf.org>; Fri, 6 Dec 2013 19:44:34 -0800 (PST)
Received: by mail-qc0-f182.google.com with SMTP id e16so1112453qcx.41 for <tls@ietf.org>; Fri, 06 Dec 2013 19:44:30 -0800 (PST)
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:date :message-id:subject:from:to:cc:content-type; bh=bmDPRzfR0h7/q5WFblgTMzgqANtiom2XETqQ2M1h8aI=; b=KtvIU6hBe1sv9elNIApcVvXrF7Jx8+MPOhDLqxiL7XQs27I6H9wsr3aRv1e4nZZgYX 6KcqBI12mV+9wwbwW+6VrX1rYOSSpijNSnpfqcQJna7FH4Od5tJX4fVlueAhXLEiPOYA h6euzp+aVsE2v2xws2ZB+Q1VykriL8kypGmg6vOs2zN0TBEftNX09+fsHTz4pyhY3i6d XlSXoV0So4B5FbzaKz6KlGx4u6+jdcaFWMlskRzqsKI1VvSK7A+6KC8dFipnTjkY4BJ6 cDJTh2UDaZha5KoWGjETuRYjuHKYRbSiPSFHKKyjBS27S5iA+qipNrBTv6fv4/UU+vBV nmDw==
X-Gm-Message-State: ALoCoQmTIzLQFSF74jOeWXDr6azWAPb+d6hhAEFntjq/5S652XMiBxShPNJ/9V+8OxC5JvipCW+K
MIME-Version: 1.0
X-Received: by 10.224.171.196 with SMTP id i4mr12617961qaz.38.1386387870429; Fri, 06 Dec 2013 19:44:30 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Fri, 6 Dec 2013 19:44:30 -0800 (PST)
X-Originating-IP: [63.245.219.53]
In-Reply-To: <1386335697.3430.31.camel@dhcp-2-127.brq.redhat.com>
References: <CAM_a8JzY8VGq+N-5YbDk_3EdXkKJzof1BtUTVY8pJev2HZ9U6g@mail.gmail.com> <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com> <CABqy+spiBPaGrk7ipeWvC2Z_B=MeDVZAmmEbXL-Pa2Lf-6UA2Q@mail.gmail.com> <1386335697.3430.31.camel@dhcp-2-127.brq.redhat.com>
Date: Fri, 6 Dec 2013 19:44:30 -0800
Message-ID: <CAFewVt5_bu1cr8UoauFSWqyGmR5hTgAnHJVKfcGG1+EnpGFcTw@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset=UTF-8
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 07 Dec 2013 03:44:35 -0000

On Fri, Dec 6, 2013 at 5:14 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> Adam's draft proposes a novel scheme. While that this is a good scheme,
> it can only be used in TLS 1.2 or later, and there will be competing
> AEAD schemes coming from the CAESAR competition. We need a
> replacement for RC4 now, that can (ideally) be patched in old
> implementations as well.

AFAICT, there's no technical reason to prohibit AEAD in TLS 1.0 or TLS 1.1.

Also, I don't think TLS 1.2 is that much code to add to a TLS 1.0 or
TLS 1.1 implementation, especially if you're not supporting any new
cipher suites except the new ChaCha20 ones, and if you're not trying
to support any functionality above what what TLS 1.0 and TLS 1.1
provide.

Consequently, I don't think we should consider the AEAD construction
to be too much of a burden for anybody to implement in order to
support new cipher suites.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)