Re: [TLS] Minutes from Tuesday

Manuel Pégourié-Gonnard <> Sat, 01 November 2014 17:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 710291A89E1 for <>; Sat, 1 Nov 2014 10:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7KRh0U2MCz4x for <>; Sat, 1 Nov 2014 10:13:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E45371A01A9 for <>; Sat, 1 Nov 2014 10:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=kjVPSwlikin9eLRBprVV2di/8FilHWOp5xgXB+OkulA=; b=VmxEf1fyqN3h57dPc/3/gUzmjyiPJeD2hRgShEs+TscvamaFkdJ73db1uXT5O3osQrHXILnXnWCoictXQg2gB34p8ghcC9VkaP9w8/sfVTQyUULFRg9EbWHa0afIV6H+KOp55BQ6hR3vxch6AvlktK1t5qcc1FOjjZGQIJK491g=;
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1XkcEj-0006bc-RE; Sat, 01 Nov 2014 18:13:14 +0100
Message-ID: <>
Date: Sat, 01 Nov 2014 18:13:18 +0100
From: Manuel Pégourié-Gonnard <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To:, Bodo Moeller <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on
Cc: "" <>
Subject: Re: [TLS] Minutes from Tuesday
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Nov 2014 17:13:24 -0000

On 31/10/2014 02:26, Martin Rex wrote:
> Bodo Moeller wrote:
>> I just don't think that the additional benefit (per connection)
>> is worth the additional computational effort (per connection), and the
>> extra latency: for many clients, there is *no* additional benefit at all.
> There is a *HUGE* benefit for clients.  They will be able to properly
> recognize accidental fallbacks that should not have happened in the
> first place.  Otherwise it takes bug reports and several years before
> client connection management failures get fixed.
It seems to me the current draft allows that too, so I don't see how your
proposal provides additional value compare to the draft on this exact point.
(I agree it does provide value compared to current situation, obviously).

>> clients will require additional code to handle this properly,
>> whereas reacting to a fatal alert is something that all TLS
>> implementations already know how to do.
> That reaction is called interop failure.  That is the far opposite
> of what IETF working groups are supposed to consciously cause to happen
> when the alternative would be to make interop succeed.
I'm not so sure. There are already a lot of situations where implementations are
requires to make the handshake fail, eg if the verify data from the Finished
message don't match, which indicates the handshake data has been tampered with.
This is not entirely different, the main difference is that the suspected
tampering happened during the previous handshake.

I'm not saying breaking the handshake is the only right thing to do, I can see
the benefits of the solution you suggest, but I think the simplicity of the
current draft is a big advantage in getting it widely (and correctly) deployed
sooner rather than later, which IMO outweighs the advantages of a more complex