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

Martin Rex <mrex@sap.com> Mon, 26 September 2011 23:41 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 B07891F0CAE for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 16:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.058
X-Spam-Level:
X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.191, 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 PWGqpAYRv6tY for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 16:41:42 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id ED1091F0CA6 for <tls@ietf.org>; Mon, 26 Sep 2011 16:41:41 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8QNiNVm013260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 01:44:23 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109262344.p8QNiMnZ010262@fs4113.wdf.sap.corp>
To: yngve@opera.com (Yngve N. Pettersen)
Date: Tue, 27 Sep 2011 01:44:22 +0200 (MEST)
In-Reply-To: <op.v2fuq8d4kvaitl@lessa-ii> from "Yngve N. Pettersen" at Sep 27, 11 01:12:34 am
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: Mon, 26 Sep 2011 23:41:42 -0000

Yngve N. Pettersen wrote:
> 
> 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).

I know that this was the original plan.

But these nice plans were foiled when Microsoft shipped their
implementation of rfc5746 with KB980436.

In retrospect, we ought to have required in rfc5746 to entirely
disable the version checking for the RSA premaster secret on the
Server side...


-Martin