IETF Logo Mail Archive

Re: [TLS] Triple Handshake Fix.

Bodo Moeller <bmoeller@acm.org> Mon, 05 May 2014 19:54 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 CB8861A0491 for <tls@ietfa.amsl.com>; Mon, 5 May 2014 12:54:46 -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 gK7JPYSPOHOi for <tls@ietfa.amsl.com>; Mon, 5 May 2014 12:54:45 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2551A047B for <tls@ietf.org>; Mon, 5 May 2014 12:54:44 -0700 (PDT)
Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0LkhPw-1XFMHD2To4-00aR82; Mon, 05 May 2014 21:54:39 +0200
Received: by mail-yh0-f54.google.com with SMTP id i57so1070937yha.13 for <tls@ietf.org>; Mon, 05 May 2014 12:54:38 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.141.113 with SMTP id f77mr50930541yhj.128.1399319678665; Mon, 05 May 2014 12:54:38 -0700 (PDT)
Received: by 10.170.65.3 with HTTP; Mon, 5 May 2014 12:54:38 -0700 (PDT)
In-Reply-To: <CAK3OfOgrXFeBEx8EWHaxvp7ZtQJ2YAap1myn5BHWKesTMCYEXA@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>
Date: Mon, 5 May 2014 21:54:38 +0200
Message-ID: <CADMpkcKTYhNAdNVypGiGu-axNWitLGRKzE3R6Rc81qJ2Jq6_bA@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=20cf303dd2285fc9d904f8ac80f8
X-Provags-ID: V02:K0:uuedErNmEl2n4Btj7lPfobr9KG501GzM+leOPBfpPvN W6Cj2ceTgb+/iFwdS48ZHRQRpUTO4rlLGNqaEpias/KO1nCU70 iFG7dvvOCvfNgA/FUSqdWY5hfOzPYdzJdhYpKClC2wrB9gSp/t LxQZGTZZ8edQqTRKwA1ZZI72fvfKDnGOtGeYKdGtAzWQ63l/G3 W4OPNFCHRjcPUR0h++uNP7zv0xdpsqownWCnY16oFqK4RVULb+ n4+H8WUAr6SWJPgowO8J5XLUJVdKHk7MeT/idFEWYnzuH0dLB9 Fb+tL+bUkT2lcQmzJGA/7yOpcHa0faaE+qMLtLhQjP02rjYyus WDmPp8vcmVt8dSYKZKarQej0Dc4C9pVFamvY/gT5cfTqY97Guv EPZ+vrb3VkDDJHmMj7q2FFAbBJahsj+e1FvjxNSX430OQ2mKQH w4Zke
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3hGOlx9mQa8JusnM6BNvKtlECJQ
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 19:56:31 -0000

Nico Williams <nico@cryptonector.com>om>:
>
> > On Wed, Apr 30, 2014 at 2:15 PM, Bodo Moeller <bmoeller@acm.org> wrote
>


> >> [...] I think we'll need a requirement for clients and servers
> >> implementing this spec to do one of the following, because an attacker
> can't
> >> be expected to opt in to extended master secrets in its handshakes:
> >>
> >> (1) If the current session does not use an extended master secret, don't
> >> allow renegotiation.
> >>
> >> (2) If a session does not use an extended master secret, don't allow it
> to
> >> be resumed.
>
> Why not both?
>

As I wrote earlier, (2) is cleaner but would entirely prevent session
resumption between updated implementations and legacy implementations, and
thus doesn't seem viable to roll out immediately.  Losing session
resumption for most connections can be significant for computational cost
and latency.

Bodo

v2.8.10 | Report a Bug | By Email