IETF Logo Mail Archive

Re: [TLS] Triple Handshake Fix.

Bodo Moeller <bmoeller@acm.org> Tue, 06 May 2014 09:49 UTC

Return-Path: <SRS0=LkZq=2E=acm.org=bmoeller@srs.kundenserver.de>
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 0B8991A028C for <tls@ietfa.amsl.com>; Tue, 6 May 2014 02:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.579
X-Spam-Level:
X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 mqee0Q4paCDE for <tls@ietfa.amsl.com>; Tue, 6 May 2014 02:49:15 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED1F1A0173 for <tls@ietf.org>; Tue, 6 May 2014 02:49:15 -0700 (PDT)
Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0M9L3K-1WYF910YVa-00CfJZ; Tue, 06 May 2014 11:49:09 +0200
Received: by mail-yh0-f46.google.com with SMTP id 29so411010yhl.33 for <tls@ietf.org>; Tue, 06 May 2014 02:49:08 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.164.198 with SMTP id c46mr56532484yhl.103.1399369748143; Tue, 06 May 2014 02:49:08 -0700 (PDT)
Received: by 10.170.65.3 with HTTP; Tue, 6 May 2014 02:49:08 -0700 (PDT)
In-Reply-To: <CAK3OfOgzjchcyThCi+51xfq1qAN_Pvi7WetEurhSoFJFBq_Vdw@mail.gmail.com>
References: <CAL9PXLyGjM0R-NRdqzbfKWOvbLjT+mwE9uT0BQTpiFt5p27ATQ@mail.gmail.com> <CALR0ui+RfdFiQ4-1Odb8DKa3Kc_Ont__eBnpMNa9Obm1FeCi2A@mail.gmail.com> <CADMpkc+JeDDebHs0G3G3f17AGw9EjOe=EcK1dh_mikKjyF1DbQ@mail.gmail.com> <CA+_8ft7fwatXJjDmcsHvXG5W+CRPAx8N1+cT9Mh86pntQ7=_vQ@mail.gmail.com> <CAK3OfOgrXFeBEx8EWHaxvp7ZtQJ2YAap1myn5BHWKesTMCYEXA@mail.gmail.com> <CADMpkcKTYhNAdNVypGiGu-axNWitLGRKzE3R6Rc81qJ2Jq6_bA@mail.gmail.com> <CAK3OfOiD3RcO2u0v+u1nxtGo31iNY_NorLtMcaCqOr3BxazPXA@mail.gmail.com> <CADMpkcLKaAMGcHmjOQzPqT=6fywgq8fhD9h7gxpvGzM6Esrb7g@mail.gmail.com> <CAK3OfOjk714z8NaMm6EuKkrVPkhHoGGwvytjA9zL1x_3=AMJ3g@mail.gmail.com> <CADMpkc+1iwE1Sy2R+ZGeZ-uiF4SHVx30HGeMU6ixVyGzrRt3=A@mail.gmail.com> <CACsn0c=fnQpwhO7FTO1zjoJT5eix9LczOuihT=Yvjbj7PzjxaA@mail.gmail.com> <CAK3OfOgzjchcyThCi+51xfq1qAN_Pvi7WetEurhSoFJFBq_Vdw@mail.gmail.com>
Date: Tue, 6 May 2014 11:49:08 +0200
Message-ID: <CADMpkc+Q1DVoYGS3mSUr0G1ds=iHOrV_B9LYJzUP+iKf0hh3Dg@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=20cf303f642cbf659004f8b8283b
X-Provags-ID: V02:K0:ozcrFDUOmEkE0DaLzXqXJ50tnMg7AI357OjiSXAorRT sRV4tv57rM7DPG0GEM4xptvcELYrl3/DywUSb+HBWmWuTIY/gW aurdO0UYPOZnzCrPcBFbzfN13zrmCUoNVVYAEz0arMl3xVY+V2 2+f88ki63pKLqCzSKHB8tbK/UY0sYI6UmTrar8Ym5ksibnFpgM mnXnAP6MaT9LAkPQDEJAWX0piwfDruxtOGbXqgtkMT/XyJYehY lB4zRYrvORz0xouiPI+pnlWX061JQxUkHwOSOSe1NZ7HbP/wCU F5DXZrLQ7EKN0WmmEnqjgM6cFzuojvy6plLHxsdQMy4e1yJpI8 hxirK+MamQzdVbxT6SZhR/sCEXpI9sd0ij3k+LTmUyvtDn6rCt anZ0BMy98elFSh/3KPLYKmoeB1WciTLDXY5dIIu9dnpj4AP2lV kuDMR
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pNBDDosXWu_eOcQ1R_WGpT5lDDs
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, 06 May 2014 10:01:01 -0000

Nico Williams <nico@cryptonector.com>om>:

> On Mon, May 5, 2014 at 4:59 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>


> > I vote for (1). Hardly anyone uses renegotation. Resumption is
> > commonly used on the web today. Let's hurt the uncommon usecase
> > instead of having a widespread performance regression.
>
> Even if we have consensus to remove renego in 1.3, for everyone else
> there's a difference between "oops, it fails" and "hmm, it's not as
> fast as usual".  This isn't hurting the uncommon use-case, but
> breaking a rare but not that rare usage.


I don't want to break renegotiation entirely, hence my suggestion to allow
servers to pick either (1) [disallow renegotiation with legacy clients] or
(2) [disallow session resumption for legacy clients] at first.

My concern regarding (2) is that "It's not as fast as usual" may actually
manifest as "My servers are suddenly overloaded and I'll have to revert the
software update".  (1) is meant for early adopters, so that they won't have
to regret being early adopters.  Past a certain stage of adoption, everyone
should just go to (2) directly.

Bodo

v2.8.10 | Report a Bug | By Email