Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

mrex@sap.com (Martin Rex) Tue, 28 January 2014 00:17 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 7540C1A0251 for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 16:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 vncHqyQJ-XL5 for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 16:17:53 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 10DE51A008F for <tls@ietf.org>; Mon, 27 Jan 2014 16:17:52 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0S0Hb1g021602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jan 2014 01:17:38 +0100 (MET)
In-Reply-To: <CADMpkcJ4viFwzU9u0uP41Niaopja8PZFowjOALVr3VA1vJ7Uow@mail.gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Date: Tue, 28 Jan 2014 01:17:37 +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: <20140128001737.D9D581ABC9@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv
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: Tue, 28 Jan 2014 00:17:55 -0000

Bodo Moeller wrote:
> Michael D'Errico <mike-list@pobox.com>:
>>
>> We should consider whether we can define a single SCSV that a
>> client issues when it thinks a server is extension intolerant.
>>
>> Such an SCSV could be used in conjunction with a normal extension
>> used for downgrade protection, if the client gets pushed all the
>> way back to TLSv1.0 without extensions, or to SSLv3.
>>
>> This approach could solve the problem of desiring more SCSVs in
>> the future.
> 
> Hm, that would mean having the SCSV for special-case downgrade protection
> (extension intolerance) and an extension for general-case downgrade
> protection (when extension intolerance is not an issue).  That means
> requiring more code to be added to servers (to *all* servers, since these
> mechanisms only work as intended if all servers support them).

But you _are_ aware that your proposal is vitally dependent that
the TLS server puts a fatal SSL alert on the wire before closing
the connection?  Historically, (close to) all applications running
on top of Microsoft SChannel (including MSIE client and IIS server)
do not send any fatal alerts before closing connections, because
they use a transport-free API (Microsoft SSPI, similar to GSS-API)
to their TLS implementation, and the application code does not support
(a) processing a fatal error messages and (b) sending tokens over
the network at the same time.  It's basically the same reason
why the forwarding of error tokens and outputs of "gss_delete_sec_context()"
was deprecated in GSS-API v2 -- because most apps will simple refuse
to do it.

It would not be possible to hide such a change in behaviour (writing
a fatal alert to the network before closing the connection) within
SChannel, it would also require a change to at least Microsoft IIS.
How likely is that going to happen?  (It's been the way it is not
for the last ~14 years...).


Which server implementers are eager to send such a fatal alert as
is contained in this proposal anyway?  I will certainly ensure that
our server implementation will NEVER grow such silly behaviour.

-Martin