Re: [TLS] Triple Handshake Fix.

Bodo Moeller <bmoeller@acm.org> Mon, 05 May 2014 20:37 UTC

Return-Path: <SRS0=RURu=2D=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 5C1C71A050E for <tls@ietfa.amsl.com>; Mon, 5 May 2014 13:37:22 -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 NA7DO-33sTFR for <tls@ietfa.amsl.com>; Mon, 5 May 2014 13:37:21 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by ietfa.amsl.com (Postfix) with ESMTP id 57C3A1A01C1 for <tls@ietf.org>; Mon, 5 May 2014 13:37:21 -0700 (PDT)
Received: from mail-yh0-f51.google.com (mail-yh0-f51.google.com [209.85.213.51]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0MIw2b-1WjLZl1pgP-002Uj0; Mon, 05 May 2014 22:37:16 +0200
Received: by mail-yh0-f51.google.com with SMTP id f10so2815434yha.10 for <tls@ietf.org>; Mon, 05 May 2014 13:37:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.145.9 with SMTP id o9mr28166125yhj.129.1399322235443; Mon, 05 May 2014 13:37:15 -0700 (PDT)
Received: by 10.170.65.3 with HTTP; Mon, 5 May 2014 13:37:15 -0700 (PDT)
In-Reply-To: <CABkgnnWwuC4BmSiNx5c9MHuGCTmJgT1ZyhKJwdR1_LW9Sxzuqw@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> <CABkgnnWwuC4BmSiNx5c9MHuGCTmJgT1ZyhKJwdR1_LW9Sxzuqw@mail.gmail.com>
Date: Mon, 05 May 2014 22:37:15 +0200
Message-ID: <CADMpkc+eKkbm1AdRGQ5DvXwZXcesaEmN24tiuVz8Yv-PdvoFGQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="20cf303f6ae8c5202804f8ad1842"
X-Provags-ID: V02:K0:72YuCwItLtBR+NS9xaKUMSUbhw/5irLK+51Bk1Go7mT 58GFtqFSTGcmwu/TQZ0LNEg5lvm915fH2xurNwGSJXAWVhlNAs lOzXY+a6OF/zk5hxeCdii9x/T9tJ+7SGOq0PSiaC2wFBvIAbzp hAHdGftxjYKSv9zdWHUaSYzQiZcVrO8JuowuuTzJJZBR+JTNpn VVRjpvduCVorBk0uzEcoMUIL28AXrSKUiwqTzg/0JejIethLYe SLglhwZaXURBSOjbijNfZYWd8MsudB5/u8f5sf4m98Dgm5UczL ivgggDwsO8wC7xWqhnr8xUK7vK1J2E/HJfTmNkJWuq+vI4Is46 Swhris3Qp2sFYihBOQ/+uCwn2SQD+iZMpolZIxl0H+qVicsy5k ZavPwtlaIKwFNGIuC6PyNRD8iMol1fHfXgicA2GdlUq3zeombu IBo8p
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F7VYmKVCSQzfFNfJ4ONUmx2_xJc
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: Mon, 05 May 2014 20:37:22 -0000

Martin Thomson <martin.thomson@gmail.com>:

> On 5 May 2014 12:54, Bodo Moeller <bmoeller@acm.org> wrote:
> > Losing session resumption for most connections can be significant for
> > computational cost and latency.
>
> At least those are the only costs.  At least the session can still be
> established.  There are some use cases that depend on renegotiation
> that cannot be addressed otherwise.  For instance, protecting client
> certificates from passive inspection.
>

Yes, that's why I also wrote, "Maybe for servers you'd initially want to
pick either approach 1 or approach 2 depending on the particular needs
(whether renegotiation is needed at all), while clients initially could
allow *both* renegotiation and resumption for new sessions, where whichever
comes first for a given session would disallow the other."


Neither option is good, but perhaps we can allow implementations (or
> deployments) to pick what measure suits them (or both).  I'd certainly
> put 2 down as the default.
>

Things definitely should converge towards (2).

Bodo