[TLS] What would make TLS cryptographically better for TLS 1.3

Watson Ladd <watsonbladd@gmail.com> Thu, 31 October 2013 20:30 UTC

Return-Path: <watsonbladd@gmail.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 B2DCB11E8110 for <tls@ietfa.amsl.com>; Thu, 31 Oct 2013 13:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 tB-JwGPL5FkT for <tls@ietfa.amsl.com>; Thu, 31 Oct 2013 13:30:35 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id F345511E8107 for <tls@ietf.org>; Thu, 31 Oct 2013 13:30:34 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id t61so3262882wes.27 for <tls@ietf.org>; Thu, 31 Oct 2013 13:30:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kUerzWDE02rYf0jK8esfwbvj7RoQ27iMtWrVJf6CpXI=; b=ebsaWQZtWxjzHXaprIlFtz8FORKgfkAJ5Q6rwB1WH1EHwn+zye4JcOjteMjqOP5ogB wFT1e4GBlWPmjCupJYznIQhJUNCXFkV2whDJvPl4OwYvVy3tOEWiBxLg+CX5pmf+LEdr ymec210tT7RnqSNg767B/hN6BaQXsUyOH8rurNAwtmqF59SIh4oPFQeCFxLuGGmWLjSz Z3TfLYSFG5S4BexULbQPX7UfQLEK1HdlvJ/W2aVDJT7OlVQiMB1DSta+yp7IftI2OdSW q7WyOO1Gz0mslnCjXwfl+Y98kqeMxcgTALte+9x5KL5huEj8WcqtVDxmbOgk7bgztucP 7ncg==
MIME-Version: 1.0
X-Received: by 10.194.122.99 with SMTP id lr3mr4422685wjb.21.1383251434039; Thu, 31 Oct 2013 13:30:34 -0700 (PDT)
Received: by 10.194.242.131 with HTTP; Thu, 31 Oct 2013 13:30:33 -0700 (PDT)
Date: Thu, 31 Oct 2013 13:30:33 -0700
Message-ID: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Thu, 31 Oct 2013 20:30:35 -0000

Print out the documentation of TLS as it stands. Then take an ax to it.
There are too many options that need to be supported. This leads to 2
implementations
which people use in the real world, both of which are horrible,
horrible nightmares to inspect and audit. We should include only those
options required by major users today.

The current MACs are all problematic. If you want to keep
authenticate-then-encrypt, make
the MAC include the requisite padding. This simplifies the job of
implementers tremendously by preventing timing attacks. Or better yet,
do encrypt-then-authenticate. Ask Rogaway for details.

We do not need CBC. Counter mode is better in every way, especially
with modern hardware support that depends on parallelizability for
maximal performance. Intel's AES instructions can have high latency,
necessitating having several encryptions in flight for performance.
Counter mode is never worse in performance. If we keep CBC, we should
do it correctly with explicit random IV.

TLS 1.3 should significantly reduce the number of round trips
required. To this end I propose the following obviously secure scheme:
the client sends a point on a curve in ClientHello and the server
responds with certificates (or some other authentication thing) and a
point on a curve, so that when the client speaks again, it is with a
negotiated, authenticated shared secret. Before everyone screams about
needing one signature per connection, note the server can use a time
based secret key, so only has to do one exponentiation per client.

Renegotiation should be killed: it serves no purpose.

RC4 must be eliminated to prevent the temptation of ever using it again.

If we must have options, to prevent deployment hassles, they must be
arranged and implementations forced to always ensure a common option
exists. Options should be included in the key derivation or signed to
prevent downgrade attacks.

Sincerely,
Watson Ladd