Re: [TLS] A la carte handshake negotiation

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 23 July 2015 02:50 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 81D331A8883 for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 19:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 NjplAKS6wNau for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 19:50:55 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E321A8861 for <tls@ietf.org>; Wed, 22 Jul 2015 19:50:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1437619854; x=1469155854; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=P43wgJtUGGRkdTWtTZLtWjjKC4cJoeMuJEFh740iqZg=; b=wQyEwLz5qr06Ys4keDTfc+rB+iJ/h9O4uF7wGtN/DbierZyzY+u9QCFm J9ibnQuiGbWoWQqkRntovqtdMxKU6Uzk5T3Or8Wrk0YHSjqsVt0F1GCOt VpiujmVvfsNREPfGOKXZecCVOJwTop0GllbTgqE8rd/n4tldMsg4O+2uy xLQZVQHA65dSOXXh8Ve+KF7dwFr1rM6CAH9z+Fv9DA+bFzuy12DOjtKwh GCFw0xpAt9l3MAvVlyeJ+h9v6G/f8wdb1w0Bk4n6Bj2nTb0h0ElIZKkIF FFqtbMznDnEPo2oV3oSQ9MKAolf+Ed0G6LSxzrPPLijae/lD45agjpRad Q==;
X-IronPort-AV: E=Sophos;i="5.15,527,1432555200"; d="scan'208";a="30120602"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 Jul 2015 14:50:52 +1200
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Thu, 23 Jul 2015 14:50:52 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] A la carte handshake negotiation
Thread-Index: AdDE8mNqdt9tbqxyQpSNJggOd5zCFg==
Date: Thu, 23 Jul 2015 02:50:52 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB06B5CB@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
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
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/GJ9nBYHvtqjRLh5e1TmLXPHTh98>
Subject: Re: [TLS] A la carte handshake negotiation
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 23 Jul 2015 02:50:59 -0000

Kyle Rose <krose@krose.org> writes:

>In that case, we should dispense with any larger key sizes and recommend
>exactly one per algorithm, and vary only on algorithm. Adopting this would
>simplify things even further by reducing the cipher set list by an order of
>magnitude.

Yup.

>Sadly, I'm guessing there are numerological requirements in various standards
>and regulations that make it necessary to keep both AES-128 and AES-256
>around, for example. There are also a ton of existing 2048-bit RSA keys that
>aren't going anywhere for a while.

You could just say "anything over 1536 bits, 1536 or 2048 recommended", which
would deal with both.

>I'm also skeptical of statements like "Using any known technology it's
>unlikely that humans can ever get beyond about 2^^100 operations", because
>that's true exactly up until it isn't.

Right, but if you're going to use that argument then AES is breakable until it
isn't, you can't find SHA-256 collisions until you can, quantum crypto can be
broken by whoever you're afraid of, and so on.

One thing we've become pretty good at doing is taking current progress on
breaking crypto and mapping out what'll happen in the future, to the point
where there have been zero sudden breaks of properly-designed algorithms (DES,
AES, IDEA, SHA, RSA, DH, and so on), ever.  In every case we've been able to
see, from a long way off, what's in store.

And to see what's in store for PKCs, you can't use the computers used by
mathematicians/numerologists, which all have infinite amounts of
zero-cycle-time memory, but the ones that actually exist in the real world.
For a 1024-bit RSA key that's around 40 terabytes of memory for the final
step, and a 1280-bit key would require roughly a petabyte of RAM, all in a
single machine or a single-machine equivalent (a standard distributed cluster
won't work because of interconnect latency problems).  So you'd need to
dedicate the entire Tianhe-2 to breaking a single 1280-bit key (I don't know
how its memory architecture will affect performance, I just chose the world's
most powerful supercomputer because that happens to be barely enough to attack
a 1280-bit key, so I'm not sure how many years of time you'd need).

Or you could just backdoor the server, which is what'll actually happen to
anyone who wants to get in.  Heck, just the interest on the power bill for the
Tianhe-2 (if you assume the computer itself comes for free) would be enough to
bribe most of the maintenance staff to plug in a trojan USB key for a minute
or two while they're cleaning.

And if you really are concerned about China secretly building a second
Tianhe-2 and using it to attack your mail server, just change your key once a
year and you're OK.

Peter.