Re: [TLS] Minutes from Tuesday

mrex@sap.com (Martin Rex) Thu, 06 November 2014 10:01 UTC

Return-Path: <mrex@sap.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 F2FAC1A1AB7 for <tls@ietfa.amsl.com>; Thu, 6 Nov 2014 02:01:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 FKrYkmiON8Ja for <tls@ietfa.amsl.com>; Thu, 6 Nov 2014 02:01:46 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715EF1A1AB5 for <tls@ietf.org>; Thu, 6 Nov 2014 02:01:46 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 9639C3A117; Thu, 6 Nov 2014 11:01:44 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 869324132B; Thu, 6 Nov 2014 11:01:44 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 812BE1AF98; Thu, 6 Nov 2014 11:01:44 +0100 (CET)
In-Reply-To: <CADMpkc+3wPmi41gvgi4w1kNyfE7-g9DMb0C7_eXnVvPbduX=Yg@mail.gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Date: Thu, 06 Nov 2014 11:01:44 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20141106100144.812BE1AF98@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ElhHwP20CseOEixNlTv54GJNCkw
Cc: Manuel Pégourié-Gonnard <mpg@polarssl.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 06 Nov 2014 10:01:49 -0000

Bodo Moeller wrote:
>
> Manuel Pégourié-Gonnard <mpg@polarssl.org>:
> 
>> Martin Rex wrote:
>>> Bodo Moeller wrote:
>>>> [...] 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.
> 
>> 
>> 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 approach.

It's actually hard to think of a more unreasonable behaviour than
the one currently specified.

A different, equally simple and magnitudes more useful server behaviour
would be for the server to continue the handshake as normal and simply
assume in the processing of the ClientHello that the Client means
ClientHello.client_version +1 compared to what it sent over the wire.

(but when doing that, the server ought to skip the RSA premaster secret
 client_version check later on when selecting a cipher suite with
 static RSA key exchange.  Since Microsoft botched the RSA premaster
 secret version on renegotiation handshakes in Win7, and there is no
 security value in the check anyway, this should be perfectly OK.)


-Martin