Re: [Cfrg] Salsa20 stream cipher in TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 21 March 2013 05:36 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D793721F8FA3 for <cfrg@ietfa.amsl.com>; Wed, 20 Mar 2013 22:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level:
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 48u9ZzPh4E8L for <cfrg@ietfa.amsl.com>; Wed, 20 Mar 2013 22:36:31 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 2589921F8FED for <cfrg@irtf.org>; Wed, 20 Mar 2013 22:36:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363844191; x=1395380191; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yL3K2zCGuCVNgX4B36InR2hI3vfUey74JCNmHghsabk=; b=opH7Ggu40EYJ9iXNC5T8NZ7ujkV6KobpleX52ljBLnINMXa/dJJSjqeY /ALgxIVC45FQMIVoc0bQQ1F23tqeyFc+dXod7gfIYkRr26LykEJhg/1Hg Q2uwFpk+JagDxcM+WrSiS8ifkZbq8IEY6MwOXI7bnwYOufvfKt37fIdfy g=;
X-IronPort-AV: E=Sophos;i="4.84,883,1355050800"; d="scan'208";a="176963893"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Mar 2013 18:36:25 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.115]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 18:36:25 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "cfrg@irtf.org" <cfrg@irtf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [Cfrg] Salsa20 stream cipher in TLS
Thread-Index: Ac4l9gauvD7G5gucTheQ1FuELorOyg==
Date: Thu, 21 Mar 2013 05:36:24 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D25628@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Cfrg] Salsa20 stream cipher in TLS
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2013 05:36:33 -0000

Geoffrey Keating <geoffk@geoffk.org>

>It also lets you do GCM, which has performance benefits over AES+SHA1.

It does?  GMAC is kind of a pig unless you've got hardware assist... and
speaking of hardware, if you're using an ASIC for it you don't have much
choice, it's mostly HMAC-SHA1 only.  Even with that aside, anyone who's really
worried about performance seems to be using RC4.

>So are we now in a catch-22 where no-one will upgrade because they don't need
>to because all the fixes are shoehorned into the current version because no-
>one will upgrade?

I'm not sure I'd characterise it as "shoehorned", a better view would be that
the existing versions fix pretty much everything that needs fixing except the
MAC-then-encrypt problem, and given that 1.2 is such a huge change that it's
almost a new protocol in parts (the change from 1.1 to 1.2 is much bigger than
the change from SSL to TLS), it's not surprising that there's no great rush to
move to it.

It's also a killer roadblock to any new changes in 1.3.  Since even the most
trivial change (to get to 1.3) will involve implementing and deploying all of
1.2, people will keep adding stuff to 1.1 rather than have to go through the
pain of 1.2 in order to add new features.  So in that sense you're right,
we're going to keep seeing changes to 1.1 rather than having them added in
1.3.  1.2 is too big a hurdle for too small a gain.

Kinda scary when you look at it like that...

Peter.