Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-00.txt
mrex@sap.com (Martin Rex) Wed, 04 July 2012 01:30 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 6A92E21F86C2 for <tls@ietfa.amsl.com>; Tue, 3 Jul 2012 18:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 LpYXPfQXIaI4 for <tls@ietfa.amsl.com>; Tue, 3 Jul 2012 18:30:07 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A33FD21F8627 for <tls@ietf.org>; Tue, 3 Jul 2012 18:30:06 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q641UD94005615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Jul 2012 03:30:13 +0200 (MEST)
In-Reply-To: <op.wgvpsyt0qrq7tp@acorna.invalid.invalid>
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Date: Wed, 04 Jul 2012 03:30:13 +0200
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: <20120704013013.154FD1A13A@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-00.txt
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, 04 Jul 2012 01:30:07 -0000
If there is anything worth considering that it would be an approach which has (a) the highest possible likelyhood to succees the TLS handshake -- which pretty much means extension-less ClientHello with ClientHello.ClientVersion either {3,0} or {3,1} (b) and simultaneously succeding that very same initial handshake with the highest common protocol version supported by both peers -- which pretty much means that the client must convey his highest supported version through a cipher suite value and that the updated server will ignore/override ClientHello.client_version when it detects the SCSV-based version negotiation. This will on the very first handshake even when the client does not cache information about the server's capabilities, and it will work without incuring failed TLS handshakes--an approach that for some software stacks would require each and every application to implement a reconnect fallback. -Martin
- [TLS] Fwd: New Version Notification for draft-pet… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] Fwd: New Version Notification for draft… Martin Rex
- Re: [TLS] Fwd: New Version Notification for draft… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] Fwd: New Version Notification for draft… Martin Rex