Re: [TLS] Protocol version for inappropriate_fallback alerts

mrex@sap.com (Martin Rex) Fri, 14 November 2014 18:52 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 DBBA61A88ED for <tls@ietfa.amsl.com>; Fri, 14 Nov 2014 10:52:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.951
X-Spam-Level:
X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, 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 yFuRgnK-HQla for <tls@ietfa.amsl.com>; Fri, 14 Nov 2014 10:52:52 -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 51D291A88F5 for <tls@ietf.org>; Fri, 14 Nov 2014 10:52:52 -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 3FF8F3A3C4; Fri, 14 Nov 2014 19:52:50 +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 30369422BB; Fri, 14 Nov 2014 19:52:50 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 25A671AFD0; Fri, 14 Nov 2014 19:52:50 +0100 (CET)
In-Reply-To: <CACsn0c=HmpZgmqohqqkq0tOoV9kMORfxmChH86PS3UWER9-3Yg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 14 Nov 2014 19:52:50 +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: <20141114185250.25A671AFD0@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ig5678_OYR_JfFLlaAZbeQ9bLAc
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 18:52:54 -0000

Watson Ladd wrote:
> Martin Rex <mrex@sap.com> wrote:
>>
>> 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.
> 
> I'm confused. The record layers in all versions of TLS are the same,
> except for the version number, until encryption is turned on, and we
> have a version negotiation mechanism. Why shouldn't the server send
> the alert using the version that version negotiation would produce?

There never is a version negotiated in this situation.

Actually, the "protocol version negotiation" is a little weird in TLS,
because the client never "offers" protocol versions to choose from,
but only indicates the highest protocol version that it supports (or
more appropriately, the highest protocol version that it is willing
to use), and the server does whatever the server feels like.

There are a number of unreasonable TLS clients that send

  record.pv = {3,3} + ClientHello.client_version = {3,3}

even when they are configured to use allow other protocol versions,
and a server that does _not_ support TLSv1.2 (or has it administratively
disabled) has two options here:

  (a) fail the handshake with a fatal protocol_version alert

  (b) successfully continue the handshake with the highest protocol
      version that the server supports and has enabled.

(a) is technically spec-compliant behaviour for pre-TLSv1.2 servers,
and it is nowhere clear that pre-TLSv1.2 server implementers will
take into accound broken TLSv1.2 clients ahead of time and do (b) 
from the beginning.


Creating specification with ambiguities or undefined behaviour,
pushing the buck to implementors, is never a good idea.
Especially if one knows that implementors have previously failed
time and time again, and when providing more elaborate guidance is easy.

-Martin