Re: [TLS] One approach to rollback protection

Nikos Mavrogiannopoulos <> Tue, 27 September 2011 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 617BB21F8E5C for <>; Tue, 27 Sep 2011 08:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.576
X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b3A3V7OsUY1G for <>; Tue, 27 Sep 2011 08:10:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C5DB221F8E5A for <>; Tue, 27 Sep 2011 08:10:43 -0700 (PDT)
Received: by wwf22 with SMTP id 22so4902634wwf.13 for <>; Tue, 27 Sep 2011 08:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4aaw6eYdxn0CiOa0C3b57AAwmeelvBYlproJ+ulA+tI=; b=M24Bv+20cbR2vR3F7LA+wGDuM31S3yCaYtX991fLNv1cunoxVz+atMlHzx3A+OBXwP LIvoiS7Nj27YobzZQ4siKtjPq+JuYaxn+Fjj8NvvPfwlC8BU1bO///BFNET7E7mrrOxq aha1aGHz9IxaRl1JBdpGjgPfPcX2drHE5vD6k=
Received: by with SMTP id p18mr4856533wbp.69.1317136400843; Tue, 27 Sep 2011 08:13:20 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id fq9sm36167224wbb.15.2011. (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:13:20 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Tue, 27 Sep 2011 17:13:34 +0200
From: Nikos Mavrogiannopoulos <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Icedove/3.1.13
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] One approach to rollback protection
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Sep 2011 15:10:45 -0000

On 09/27/2011 04:51 PM, Dan Winship wrote:
> On 09/26/2011 07:44 PM, Eric Rescorla wrote:
>>     The natural defense against this attack is to have a "maximum
>>     version" indicator which the client can safely send even to downrev
>>     servers but which upgraded servers can check and will thus allow
>>     downgrade detection.
> You don't even need to indicate maximum version. The client just needs
> to indicate "I've downgraded". Clients will never downgrade against a
> server that implements version negotiation correctly, so if a compliant
> server sees that flag, it knows there's an attack in progress.

The problem is that many servers support TLS 1.0 but they are so buggy 
(e.g. fail when seeing extensions or fail if padding in record packets 
exceeds the cipher block size) that clients downgrade in order to talk 
to them. In that case the server would see that as an attack. Adding 
such a protection could add more compatibility issues.

I think the goal should be to eliminate the need for downgrade and use 
the protocol negotiation of TLS.