Re: [TLS] One approach to rollback protection

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 29 September 2011 06:35 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 38A1B21F8D56 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 23:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level:
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 6l9B7wa2oTdj for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 23:35:06 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 237B321F8D52 for <tls@ietf.org>; Wed, 28 Sep 2011 23:35:05 -0700 (PDT)
Received: by wwf22 with SMTP id 22so336995wwf.13 for <tls@ietf.org>; Wed, 28 Sep 2011 23:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e70sjpivVZqeHEbnbQENaFnkTRyNWduiwwwPrCecKnw=; b=o1GZ3+St8jFF/2T6Cd2krb14blxfdgMzOw4gRqelGP3OUVE/aGDTFMxaOhRZxmFm3U LWpU2UKHBwgEKBlXKuNOJMvB7IaCbc/qnx8BS60GL5IIa3w7WpOkF9TAzRL2MRTpv/nG oyg8PVlIdhK4+HPo04b7bdlq8/SdsdvL7L6eg=
Received: by 10.227.11.149 with SMTP id t21mr2883765wbt.39.1317278274727; Wed, 28 Sep 2011 23:37:54 -0700 (PDT)
Received: from [10.100.2.14] (94-225-167-75.access.telenet.be. [94.225.167.75]) by mx.google.com with ESMTPS id fy13sm917665wbb.18.2011.09.28.23.37.53 (version=SSLv3 cipher=OTHER); Wed, 28 Sep 2011 23:37:53 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4E841253.9060605@gnutls.org>
Date: Thu, 29 Sep 2011 08:38:11 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13
MIME-Version: 1.0
To: mrex@sap.com
References: <201109282257.p8SMv5P1019589@fs4113.wdf.sap.corp>
In-Reply-To: <201109282257.p8SMv5P1019589@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] One approach to rollback protection
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: Thu, 29 Sep 2011 06:35:07 -0000

On 09/29/2011 12:57 AM, Martin Rex wrote:

>> - Forward compatibility. How does a X-year old server that support TLS 1.2
>> understand that that new cipher suite code point is not some new cipher it
>> does not support, but an indication that the client support TLS 1.5? The
>> codepoints would have to not just be predictable, but the codepoints would
>> also have to work for TLS NG using protocol version 4.1. How far ahead do
>> we reserve codepoints, how much of the ciphersuite codepoint space will
>> this eat up? Or do we assume that any TLS 1.2+ server is version and
>> extension tolerant, so TLS 1.2 is the highest version we will ever need to
>> assign a code point for?

> I do _not_ want to retire the original TLS version negotiation,
> just like to see an alternative "hinting" being standardized to
> accomodate a ~10 year transition period to get over TLS version-related
> interop problems that exist in today's installed base.

For what reason? Since more and more people demand TLS 1.1 support more 
and more servers will make sure that they interoperate with it. Creating 
a new approach to negotiate versions might even create more 
interoperability problems. Why do you think implementers that got wrong 
the original simple negotiation will get right this one?

regards,
Nikos