Re: [TLS] interop for TLS clients proposing TLSv1.1

Martin Rex <mrex@sap.com> Wed, 21 September 2011 23:18 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313501F0D33 for <tls@ietfa.amsl.com>; Wed, 21 Sep 2011 16:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.053
X-Spam-Level:
X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED7ri2yaCDXV for <tls@ietfa.amsl.com>; Wed, 21 Sep 2011 16:18:16 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8811F0D31 for <tls@ietf.org>; Wed, 21 Sep 2011 16:18:08 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8LNKWx6007847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 01:20:33 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109212320.p8LNKWl5023077@fs4113.wdf.sap.corp>
To: geoffk@geoffk.org (Geoffrey Keating)
Date: Thu, 22 Sep 2011 01:20:32 +0200 (MEST)
In-Reply-To: <m27h51ecb8.fsf@localhost.localdomain> from "Geoffrey Keating" at Sep 21, 11 03:54:35 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 21 Sep 2011 23:18:17 -0000

Geoffrey Keating wrote:
> 
> 
> > Does anyone (SSL Labs, Opera, others) have any figures/stats about the
> > current "TLSv1.1 version (in)tolerance" for TLS servers on the public
> > internet?
> 
> I find that about 1.4% of servers will refuse to connect using a TLS 1.2
> hello but will connect using a TLS 1.0 hello.  Some of those might be
> unhappy about something else in the TLS 1.2 hello (extensions, for
> example).  The other 99% accept a TLS 1.2 hello, even though only a small
> fraction (about 0.15%) actually supports TLS 1.1 or 1.2.
> 
> > The TCP RST in the above situation, as described in Stevens' Network
> > Programming, Section 7.5, Socket Option SO_LINGER, only indicates the
> > specific SO_LINGER setting that the server had used for his side
> > of the connection / his socket (Fig. 7.10  close() l_onoff=1, l_linger=0)
> > 
> > The SO_LINGER setting for a socket is entirely at the discretion of each peer
> > and closing the socket immediately after sending a fatal alert is exactly
> > what the TLS spec suggests:
> > 
> >    http://tools.ietf.org/html/rfc2246#section-7.2.2
> > 
> >    7.2.2. Error alerts
> > 
> >    Error handling in the TLS Handshake protocol is very simple. When an
> >    error is detected, the detecting party sends a message to the other
> >    party. Upon transmission or receipt of an fatal alert message, both
> >    parties immediately close the connection. 
> > 
> >           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!
> 
> RFC 793 says, in section 3.5, that a connection is closed by sending a
> FIN.  A RST is not a close of the connection but an abort; as RFC 793
> says, "Such a message indicates to the site B TCP that something is
> wrong, and it is expected to abort the connection."

Your on the wrong page, see RFC1122 Section 4.2.2.13.
Sending RST on cluse, indicating loss of data (that includes future
loss of data).

When not lingering on close, the server closes and destroys the socket
immediately, there will not be a graceful three way handshake and the
server does not care whether the data is received by the recipient,
not even whether the data is delivered by the network.


> 
> However, the question of how to close the connection is secondary,
> because it should not have been closed in the first place; as the blog
> entry says, "The server isn't supposed to behave this way---it's
> instead expected to simply reply using the latest HTTPS protocol
> version it supports".  You can't really expect software that's broken
> in one way to work perfectly in all other ways...
 

You're missing the point.  The blog is describing a reconnect fallback
implemented in WinINET, and writes that the fallback fails to work
because the server behaves incorrectly.  This is wrong,  The server
behaviour is perfectly fine, but the described reconnect fallback
logic is flawed.


-Martin