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

Watson Ladd <> Fri, 01 November 2013 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 604BE11E80E9 for <>; Fri, 1 Nov 2013 15:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.545
X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ztNHpK36RUBS for <>; Fri, 1 Nov 2013 15:40:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::231]) by (Postfix) with ESMTP id E86E111E8110 for <>; Fri, 1 Nov 2013 15:40:25 -0700 (PDT)
Received: by with SMTP id x55so117371wes.8 for <>; Fri, 01 Nov 2013 15:40:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bOrdDq8Ki+Zly0FF3+5VBNlJQ6QqP/0nN/7iOSqoP/g=; b=qwwJCSOZ+UFo7jvOchRIwmwl1MDzZS/znJDReaJ2eUK+xqDX/RzLty4LHJFiQVD1Fg +5PE70GwAQnNxeUDR5RCh0eoPBzyelL9O8sM+0a/pGTyxlA2c2LpPkQbMu8sPiidNa9e NCeGxUzSSMbwdIFFEOCZTes7tkOVDsmOow792qAUrj6uMq2ICcnZeUH/VmChlUpnxZYe OYf6UZ1/c0/9ysPPGWyxbbgr0F/qrG+4ssCdB1J6Wkq2S35P12C/GShdi5vIuZrXU0b+ u9SvaYYx1o86vdZJPNDSjJWKAEa8DQIqF8j970Hol3bh9ef6gffbO/B4ThIOzVQa+c58 aOnA==
MIME-Version: 1.0
X-Received: by with SMTP id vp8mr4112322wjc.45.1383345625231; Fri, 01 Nov 2013 15:40:25 -0700 (PDT)
Received: by with HTTP; Fri, 1 Nov 2013 15:40:25 -0700 (PDT)
Received: by with HTTP; Fri, 1 Nov 2013 15:40:25 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 1 Nov 2013 15:40:25 -0700
Message-ID: <>
From: Watson Ladd <>
To: "rransom. 8774" <>
Content-Type: multipart/alternative; boundary=001a11c1b45297f82d04ea2540bc
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Nov 2013 22:40:27 -0000

On Nov 1, 2013 2:21 PM, "Robert Ransom" <> wrote:
> On 10/31/13, Watson Ladd <> 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.)
The PQ transition involves reworking the PKI as well. We also don't know if
NTRU or something else will win. A proffered version byte to avoid
downgrades could work, but I would not want to commit to the future.
> 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
> * 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.
After one zettabyte according to a simple calculation.
> * Applications can also use renegotiation-based rekeying to improve
> forward secrecy; for example, the Mixminion specification
> (<
> section 4, line 1040) requires that relay-to-relay TLS connections be
> rekeyed using renegotiation every 15 minutes for this purpose.
If reconnecting is cheap enough that works. Designers need to deal with
connection death anyway.
> * 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.
What does renegotiation get here?
The untrusted device can do everything unless it is being monitored by a
trusted device.
> * 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.
TOR could send a temporary outer signature and an inner proof. I agree this
is a weakness, but CurveCP like mechanisms only work thanks to some known
> Robert Ransom