IETF Logo Mail Archive

Re: [TLS] Triple Handshake Fix.

Nico Williams <nico@cryptonector.com> Tue, 29 April 2014 23:43 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8C71A09A2 for <tls@ietfa.amsl.com>; Tue, 29 Apr 2014 16:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uzlRKQishDc for <tls@ietfa.amsl.com>; Tue, 29 Apr 2014 16:43:00 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9270B1A0948 for <tls@ietf.org>; Tue, 29 Apr 2014 16:43:00 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 593EE2007DA14 for <tls@ietf.org>; Tue, 29 Apr 2014 16:42:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=DQEVZLCKL9Vy0iRqKGJS FJ6j/iM=; b=t9abDzvn5FsipyfNtnIN/My9S0xHFkLLHiOPI7FjD1wzU9+L7Lxn 0kAt3J0TWGT6SOpOJuvfYRTyf9n5W/HrgqSIM0Ro5I3ASdmQZtHiX/RxzkHE38pi co6A60n7t0NrCIErrUiNNTPEAFR6N+K79vxRaTLYfM5gfRClV/rN43I=
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 0EB592007DA13 for <tls@ietf.org>; Tue, 29 Apr 2014 16:42:58 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id k48so919870wev.19 for <tls@ietf.org>; Tue, 29 Apr 2014 16:42:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.108.147 with SMTP id hk19mr704691wib.42.1398814977850; Tue, 29 Apr 2014 16:42:57 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Tue, 29 Apr 2014 16:42:57 -0700 (PDT)
In-Reply-To: <CABkgnnWx2Ch1gn3uc-ArtF2EBQMPNheXk1S0UdEN1PKMGLk9QQ@mail.gmail.com>
References: <CAL9PXLyGjM0R-NRdqzbfKWOvbLjT+mwE9uT0BQTpiFt5p27ATQ@mail.gmail.com> <CAK3OfOiDBp=1HOSPxUKsv8KjBnZQT_=0sfFOKbA3L5ftvKGSwQ@mail.gmail.com> <CABkgnnWx2Ch1gn3uc-ArtF2EBQMPNheXk1S0UdEN1PKMGLk9QQ@mail.gmail.com>
Date: Tue, 29 Apr 2014 18:42:57 -0500
Message-ID: <CAK3OfOij0U4qJ_-NojcPVztmgtTpm1SK4km2b0t7fF6hgTzvTQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3AGSU7g_zzuSpvNj_DQqJ8gwrZ0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Triple Handshake Fix.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 29 Apr 2014 23:43:01 -0000

On Tue, Apr 29, 2014 at 6:11 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 29 April 2014 15:02, Nico Williams <nico@cryptonector.com> wrote:
>> tls-unique is fine provided resumption isn't broken.  Resumption is
>> broken.  There is a proposed fix[2] that IMO is correct and works.
>
> So the proposed fix doesn't do anything about resumption, it changes

That's quibbling.  Something is broken in TLS leading to tls-unique CB
being vulnerable among other things.  There is a fix that effectively
channel binds the new connection to the one being resumed, and this
naturally solves the problem.

> the derivation of the master secret.

Right.

> I think that the proposed fix is the right one - one we should be
> fixing for TLS <=1.2.  There are probably better options for fixing
> 1.3.

I agree as to fixing TLS <= 1.2.  I don't think there is a better
option for 1.3 (short of removing resumption, as some have proposed),
therefore it's also the correct fix for 1.3 (assuming no major changes
like dropping Finished messages as Watson Ladd proposed, which would
require updating tls-unique concurrently).

Nico
--

v2.23.0 | Report a Bug | By Email