Re: [TLS] interop for TLS clients proposing TLSv1.1
"Yngve N. Pettersen" <yngve@opera.com> Mon, 26 September 2011 23:09 UTC
Return-Path: <yngve@opera.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 A47BF21F8D2A for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 16:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.562
X-Spam-Level:
X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 xvL4flqbj0xi for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 16:09:55 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 008C921F8D0D for <tls@ietf.org>; Mon, 26 Sep 2011 16:09:54 -0700 (PDT)
Received: from lessa-ii (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p8QNCU49028821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Sep 2011 23:12:32 GMT
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: Florian Weimer <fweimer@bfk.de>, Martin Rex <mrex@sap.com>
References: <201109261427.p8QERf9g008042@fs4113.wdf.sap.corp>
Date: Tue, 27 Sep 2011 01:12:34 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@opera.com>
Organization: Opera Software ASA
Message-ID: <op.v2fuq8d4kvaitl@lessa-ii>
In-Reply-To: <201109261427.p8QERf9g008042@fs4113.wdf.sap.corp>
User-Agent: Opera Mail/10.62 (Win32)
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
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: Mon, 26 Sep 2011 23:09:56 -0000
On Mon, 26 Sep 2011 16:27:41 +0200, Martin Rex <mrex@sap.com> wrote: > It seems that no TLS client that propose TLSv1.1 or higher today > would want to do so without a reconnect fallback facility in place. > The problem of the reconnect fallback is, that it precludes a protected > negotiation of the TLS version. As long as there is no way to tell if a server is negotiating version correctly, then we do need a fallback mechanism. It is, however, a mechanism that for HTTPS, at least, is becoming less needed, as I indicated earlier in this thread. I also think we have a mechanism now that can be used as an indicator that the server can negotiate version in the required fashion, without needing a fallback system: The Renegotiation Indication Extension. The Renego specification contain a reminder about version and extension tolerance being required. (Yes, I lobbied for the inclusion of that particular text). My testing indicates that the tolerance is included in most Renego patched servers. The failure rate in my sample is 0.092% up to and including TLS 1.2, mostly extension intolerance. The version intolerance for version code 3.x >= 3.4 is 0.049%. There is some problems with the 4.x+ range, though, due to a missing patch at at least one vendor. (To compare the numbers, this is slightly less than the number of servers that may break if the patch suggested for the BEAST issue is implemented, according to my testing.) My suggestion is that clients that use a fallback policy to an older version than their highest supported version, in case negotiation fails, should always negotiate with their highest version indicated if the server is detected as having been Renego patched, and then not fall back in case negotiation fails. That would essentially eliminate the version rollback potential, at least without a weakness being discovered in the protocol integrity check itself. One way to implement such a policy is that the client starts with TLS 1.0 + extensions, and only upgrade to TLS 1.1 or TLS 1.2 if it detects that the server is renego patched. Alternatively (and I prefer this), the client can start with a higher version, and fall back as needed (currently for 1.8% of the sites), but go back up if the server is detected as Renego patched. This would have the benefit that the client saves time when connecting to 98+% of the servers, by not needing a fallback or an upgrade in a new connection. Currently, 30% (463) of the (max) TLS 1.1 servers are not renego patched servers, only a single of the 133 registered TLS 1.2 servers isn't patched. This group is 0.2% of the unpatched servers (39.9%). I doubt that any other mechanism will work better, and deployment will be at least 3 years behind the Renego curve, and will probably have a lower server deployment rate than Renego. Let's see if we can work with what we have, before we design a new mechanism. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ********************************************************************
- [TLS] interop for TLS clients proposing TLSv1.1 Martin Rex
- Re: [TLS] interop for TLS clients proposing TLSv1… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] interop for TLS clients proposing TLSv1… Yoav Nir
- Re: [TLS] interop for TLS clients proposing TLSv1… Martin Rex
- Re: [TLS] interop for TLS clients proposing TLSv1… Martin Rex
- Re: [TLS] interop for TLS clients proposing TLSv1… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] interop for TLS clients proposing TLSv1… Geoffrey Keating
- Re: [TLS] interop for TLS clients proposing TLSv1… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] interop for TLS clients proposing TLSv1… Martin Rex
- Re: [TLS] interop for TLS clients proposing TLSv1… Martin Rex
- Re: [TLS] interop for TLS clients proposing TLSv1… Geoffrey Keating
- Re: [TLS] interop for TLS clients proposing TLSv1… Peter Gutmann
- Re: [TLS] interop for TLS clients proposing TLSv1… Florian Weimer
- Re: [TLS] interop for TLS clients proposing TLSv1… Martin Rex
- Re: [TLS] interop for TLS clients proposing TLSv1… Yngve N. Pettersen
- Re: [TLS] interop for TLS clients proposing TLSv1… Bill Frantz
- Re: [TLS] interop for TLS clients proposing TLSv1… Martin Rex
- Re: [TLS] interop for TLS clients proposing TLSv1… Nikos Mavrogiannopoulos
- Re: [TLS] interop for TLS clients proposing TLSv1… Juho Vähä-Herttua