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
- [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-0… internet-drafts
- [TLS] Protocol version for inappropriate_fallback… Florian Weimer
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Florian Weimer
- Re: [TLS] Protocol version for inappropriate_fall… Martin Thomson
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Martin Thomson
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Florian Weimer
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Florian Weimer
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Ben Laurie
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Watson Ladd
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex