Re: [TLS] Protocol version for inappropriate_fallback alerts

mrex@sap.com (Martin Rex) Fri, 14 November 2014 17:32 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 F34B81A1B26 for <tls@ietfa.amsl.com>; Fri, 14 Nov 2014 09:32:20 -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 kUc7b0f9IkE3 for <tls@ietfa.amsl.com>; Fri, 14 Nov 2014 09:32:19 -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 EF0061A1B35 for <tls@ietf.org>; Fri, 14 Nov 2014 09:31:54 -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 69AE63A40F; Fri, 14 Nov 2014 18:31:53 +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 570BA42C41; Fri, 14 Nov 2014 18:31:53 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 4C6DC1AFD0; Fri, 14 Nov 2014 18:31:53 +0100 (CET)
In-Reply-To: <CABrd9SQxgb2e4jXu+adbUwWwn7TbXHOCeF+EM3Th2TmwpehP3w@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Date: Fri, 14 Nov 2014 18:31:53 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141114173153.4C6DC1AFD0@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0k3-517s8yFLDC6ZRIijiiKYtcs
Cc: Florian Weimer <fweimer@redhat.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts
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: Fri, 14 Nov 2014 17:32:21 -0000

Ben Laurie wrote:
> Martin Rex <mrex@sap.com> wrote:
> 
>> Keep in mind that there is the general IETF rule
>>
>> "Be liberal in what you accept, be conservative in what you send",
> 
> This "rule" is terrible for security and absolutely should not be followed.

You seem to have missed it, but what we were discussing here
is a guidance for the server which protocol version the server should
use at the record layer when returning the fatal invalid_fallback
alert to the client.

The protocol_version that that the server uses will *NOT* affect the
fatal failure of the handshake (for the server), but may affect the
behaviour of the client and the comprehensibility of the error message
that the client produces, so this is *EXACTLY* the kind of situation
where the general IETF rule applies.

-Martin