Re: [TLS] Protocol version for inappropriate_fallback alerts

mrex@sap.com (Martin Rex) Sat, 15 November 2014 04:23 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 4AB2E1A0AF1 for <tls@ietfa.amsl.com>; Fri, 14 Nov 2014 20:23:13 -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 Efu3jrkb7a0R for <tls@ietfa.amsl.com>; Fri, 14 Nov 2014 20:23:09 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB571A0AC8 for <tls@ietf.org>; Fri, 14 Nov 2014 20:23:08 -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 smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 665863A2FA; Sat, 15 Nov 2014 05:23:06 +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 56C2E42599; Sat, 15 Nov 2014 05:23:06 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 4EB711AFD4; Sat, 15 Nov 2014 05:23:06 +0100 (CET)
In-Reply-To: <CADMpkcLL0VC3FOZ0N+AUt6VYVAJd3uQu=5_JsPxUAJbLjg1R7Q@mail.gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Date: Sat, 15 Nov 2014 05:23:06 +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: <20141115042306.4EB711AFD4@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_7OvzahMHpg_HNr8kdVf6XBRR40
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: Sat, 15 Nov 2014 04:23:13 -0000

Bodo Moeller wrote:
> Martin Rex <mrex@sap.com>:
> 
>> Creating specification with ambiguities or undefined behaviour,
>> pushing the buck to implementors, is never a good idea.
> 
> Now I am thoroughly confused by what you're saying. A bit earlier you
> argued *against* specifying a MUST for the record-layer version number to
> be used with the inappropriate_fallback alert (as it appears in
> draft-ietf-tls-downgrade-scsv-02), proposing instead a wording that you
> said was "vague on purpose". I can't reconcile that with what you're saying
> here. The only constant theme I can make out is that whatever you're saying
> at a given time is undoubtedly right.


Giving a implementors a guidance by describing the issue at hand
calling for reasonable trade-offs and and recommending, but not mandating
certain behaviour, promotes interop.


Using imperatives where this isn't necessary is not only squarly in
conflict with rfc2119, it will also result in interop failures, because
it gives (some) implementors poor excuses for why their code aborts or
fails interop in a neither useful nor reasonable fashion.


-Martin