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

Nico Williams <nico@cryptonector.com> Fri, 01 November 2013 21:28 UTC

Return-Path: <nico@cryptonector.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 E5A5011E8184 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 14:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level:
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 ZVtl1BG-s2MZ for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 14:28:46 -0700 (PDT)
Received: from homiemail-a64.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70311E8166 for <tls@ietf.org>; Fri, 1 Nov 2013 14:28:42 -0700 (PDT)
Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 0BAAC43806C; Fri, 1 Nov 2013 14:28:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=WUP68dzBS8tCIT UTW07DjuOVMk4=; b=hc75WMOuZ6rt+19u2FStao7GQtG8MZM4z9LRtBr9uXjYlg qKJCvGbo6OUipoudSZNqzVFnWOzdbXA8YBgua+hbX/K80FM8UHYybzitQSTsiSIA sCNIjieEmwC0cE6+ZH6Lra90UU8kqDbmoeY8J9ApJyAhTmZgUrr3QWJQundqY=
Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 93D2543801C; Fri, 1 Nov 2013 14:28:40 -0700 (PDT)
Date: Fri, 1 Nov 2013 16:28:37 -0500
From: Nico Williams <nico@cryptonector.com>
To: Robert Ransom <rransom.8774@gmail.com>
Message-ID: <20131101212834.GE32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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:28:51 -0000

On Fri, Nov 01, 2013 at 02:21:35PM -0700, Robert Ransom wrote:
> On 10/31/13, Watson Ladd <watsonbladd@gmail.com> wrote:
> 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.

Sure.

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

This can be done without a synchronous renegotiation by just computing a
new sessionkey every so many bytes/blocks/records (whatever's
appropriate to count for the cipher in use).

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

Indeed.  Speaking of which, resumption must support PFS rekeying.

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

As long as there's no MITM...

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

I thought this was no longer in use.

Also:

 * Privacy protection for the user's PSK ID and/or cert and/or other
   identifying data.

   But again, an NPN-style extension should take care of this.

 * Relatedly, the server can request user authentication asynchronously,
   in which case NPN-style extensions don't help.

   I'd be happy to get rid of this: user authentication in such cases
   belongs in the app layer.  However, it may not be feasible to get rid
   of such uses of renegotiation, so it probably has to stay :(

Nico
--