Re: [TLS] One approach to rollback protection
Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 27 September 2011 15:10 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 617BB21F8E5C for <tls@ietfa.amsl.com>; Tue, 27 Sep 2011 08:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.576
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3A3V7OsUY1G for <tls@ietfa.amsl.com>; Tue, 27 Sep 2011 08:10:44 -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 C5DB221F8E5A for <tls@ietf.org>; Tue, 27 Sep 2011 08:10:43 -0700 (PDT)
Received: by wwf22 with SMTP id 22so4902634wwf.13 for <tls@ietf.org>; Tue, 27 Sep 2011 08:13:21 -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: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 10.227.10.146 with SMTP id p18mr4856533wbp.69.1317136400843; Tue, 27 Sep 2011 08:13:20 -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 fq9sm36167224wbb.15.2011.09.27.08.13.19 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:13:20 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4E81E81E.2090404@gnutls.org>
Date: Tue, 27 Sep 2011 17:13:34 +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: tls@ietf.org
References: <CABcZeBNFtVBh7a=j4LE73Q0c-W8KGe4aKNBVZam1qOZr=aRaRQ@mail.gmail.com> <4E81E2E1.3020604@gmail.com>
In-Reply-To: <4E81E2E1.3020604@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: 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: >> http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt > >> 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. regards, Nikos
- [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Nico Williams
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Adam Langley
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Adam Langley
- Re: [TLS] One approach to rollback protection Marsh Ray
- Re: [TLS] One approach to rollback protection Juho Vähä-Herttua
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Yoav Nir
- Re: [TLS] One approach to rollback protection Dan Winship
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Badra
- Re: [TLS] One approach to rollback protection Matt McCutchen
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Yngve N. Pettersen
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Martin Rex