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

Robert Ransom <rransom.8774@gmail.com> Fri, 01 November 2013 21:21 UTC

Return-Path: <rransom.8774@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 DB3D111E8160 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 14:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 XQQiFb+ndeBN for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 14:21:36 -0700 (PDT)
Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0199111E8155 for <tls@ietf.org>; Fri, 1 Nov 2013 14:21:35 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id ii20so903931qab.17 for <tls@ietf.org>; Fri, 01 Nov 2013 14:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p6/qHxinojm/fOp4dbBvz3i1ANh4Yiq4Ui+TlxZ3JqQ=; b=Cgbos4mOCCoN+VsNMWjC75L6bR8U/9Ccl73+LleQBkWT3DiWI/vCf7GbniLV5FsWTa usznC00S8SdWDDFGDsX8DqkumMW5cpw0UpCTPf2TIrG0oO/RM34wrzib2grvU72Mm/pT GyFX9M9JCXWs05mixK7w7E6bRIXbXB7bn37ICGyGIct3azoRsBwcIEX2rp+KTibBUUkr v2GPjVNmtraQw5+GeP0axG5C51YehQw2n3Yr59c3n0u7F7pr5zSZnl/PhTomJm374+xq NPae+0vnkVkULrHIwg60GaVEz6S5JbK7LWdPQsEdRAmbS7Ec3S96Uvw+FuB7r1/tTGdT Dj/A==
MIME-Version: 1.0
X-Received: by 10.49.61.9 with SMTP id l9mr6750863qer.64.1383340895474; Fri, 01 Nov 2013 14:21:35 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Fri, 1 Nov 2013 14:21:35 -0700 (PDT)
In-Reply-To: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com>
Date: Fri, 1 Nov 2013 14:21:35 -0700
Message-ID: <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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: Fri, 01 Nov 2013 21:21:37 -0000

On 10/31/13, Watson Ladd <watsonbladd@gmail.com> wrote:

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

This protocol should be designed to allow future extension to use
post-quantum encryption and/or key encapsulation cryptosystems.  (I
don't believe that quantum computers will become a threat, but some PQ
cryptosystems may be faster than ECDH.)

It also needs to either allow session resumption without the
possibility of reusing any key used to encrypt or authenticate
application-level data, or explicitly forbid session resumption.


> Renegotiation should be killed: it serves no purpose.

Renegotiation is a critical feature of TLS, which serves multiple purposes.

* Renegotiation allows rekeying of a session.  This is absolutely
required for any ciphersuite based on a block cipher with a 128-bit or
smaller block, because block cipher modes' security properties degrade
after they are used for more than some number of blocks.

* Applications can also use renegotiation-based rekeying to improve
forward secrecy; for example, the Mixminion specification
(<https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt>,
section 4, line 1040) requires that relay-to-relay TLS connections be
rekeyed using renegotiation every 15 minutes for this purpose.

* A TLS connection can be established by a fully trusted device which
knows a password or other application-layer authorization credential,
authorized to perform some operations using messages within the TLS
connection, and then transferred with the help of renegotiation to a
less trusted device to actually perform those operations.  This is
similar to the preceding use, but to provide 'sideways secrecy' rather
than forward secrecy.

* One version of the Tor 'link protocol' (Tor's term for its outer
TLS-based connection protocol) uses renegotiation to provide secrecy
for the server's certification chain against purely passive attackers.
 The purposes above could be served by applying a one-way function to
the originally derived key material, then discarding the old keys;
this purpose cannot.


Robert Ransom