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