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

Andy Lutomirski <luto@amacapital.net> Fri, 01 November 2013 23:05 UTC

Return-Path: <luto@amacapital.net>
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 EAA1E11E8153 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 16:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 2605R7qnrYjt for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 16:05:07 -0700 (PDT)
Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id B93E711E8136 for <tls@ietf.org>; Fri, 1 Nov 2013 16:05:05 -0700 (PDT)
Received: by mail-pb0-f43.google.com with SMTP id md4so4862268pbc.16 for <tls@ietf.org>; Fri, 01 Nov 2013 16:05:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b+Le7FeMwHK/wqqyVk5YYAIq02j1fZxCjJoSXg0Dhlw=; b=NrkwMCtrZhB5LHXjZHBP1SwYLDAw25z58gA1aR17TzFLfAz5ZmbPRpy6tSjBfhbMJ5 VVAJitirtdMIyy/xbYFDEjKybdfy+LC/DD1AwJDBW/FpV2sGt6bg0H6f66gUle+J3vTt Et5uN1ECTQyfGSA7jfFLp0ZGKbSJ5cFL+SlK9X2+QJfkdUtxyD7S6P/SJfIMEPS5e6jd ItVNINHuBcVWKE/qPLGA/3YacONfWgXuhd9Ga7MHjKesXDVL01vEVKB/uNnjqntyyzxK s7zBSwaEfabCME83DodbmSCqKmD5bHBK5Pqm84AU4aDzbaJSGgsTy2iyCrdxgA7dp1vb KIgA==
X-Gm-Message-State: ALoCoQmYFrlyQI3v/lK4jwNwhBCsRQO8ck4MVCDEUeTkHUtnIcwSJypla2vcUWWfysQo/mBO1YKn
X-Received: by 10.69.31.203 with SMTP id ko11mr5339489pbd.127.1383347104506; Fri, 01 Nov 2013 16:05:04 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id go4sm13121723pbb.15.2013.11.01.16.05.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 16:05:03 -0700 (PDT)
Message-ID: <5274339D.9090200@mit.edu>
Date: Fri, 01 Nov 2013 16:05:01 -0700
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Robert Ransom <rransom.8774@gmail.com>, Watson Ladd <watsonbladd@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
In-Reply-To: <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sat, 02 Nov 2013 07:02:44 -0700
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 23:23:22 -0000

On 11/01/2013 02:21 PM, Robert Ransom wrote:
> 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.)

I've yet to see one that's remotely competitive in both performance and
message size.  IIRC, the NTRU algorithms have some serious security
questions and the LWE and McEliece-like algorithms have enormous public
keys.

That being said, being ready for quantum computers if and when they show
up is a good idea.  (Note that everything will need to be upgraded to
256-bit security if real quantum computers show up, regardless of
public-key breaks.)

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

Renegotiation is a really heavy-weight way to do this.  Just have both
sides apply some irreversible transformation to the master secret every
now and then.  (For example, they could hash the keys and throw away the
originals.)


OTOH, using renegotiation to request a client certificate after you've
seen the URL is useful.  But this doesn't actually need a change of
cipher -- it just needs the client to prove its identity.

--Andy

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