IETF Logo Mail Archive

Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 12 November 2009 01:22 UTC

Return-Path: <pgut001@wintermute01.cs.auckland.ac.nz>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7E828C172 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 17:22:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.028
X-Spam-Level:
X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LaLdNgsXcDk for <tls@core3.amsl.com>; Wed, 11 Nov 2009 17:22:04 -0800 (PST)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 3A07428C165 for <tls@ietf.org>; Wed, 11 Nov 2009 17:22:02 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 748A09CDB0; Thu, 12 Nov 2009 14:22:26 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i56DCHYaLYae; Thu, 12 Nov 2009 14:22:26 +1300 (NZDT)
Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B37DA9CDFC; Thu, 12 Nov 2009 14:22:23 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1N8OOF-00014c-Hj; Thu, 12 Nov 2009 14:22:23 +1300
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1N8OOF-0007Ee-BG; Thu, 12 Nov 2009 14:22:23 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: marsh@extendedsubset.com, mrex@sap.com, ynir@checkpoint.com
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB4@il-ex01.ad.checkpoint.com>
Message-Id: <E1N8OOF-0007Ee-BG@wintermute01.cs.auckland.ac.nz>
Sender: pgut001 <pgut001@wintermute01.cs.auckland.ac.nz>
Date: Thu, 12 Nov 2009 14:22:23 +1300
Cc: tls@ietf.org
Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 12 Nov 2009 01:22:05 -0000

Yoav Nir <ynir@checkpoint.com> writes:

>I disagree that it's a waste to repurpose the entire 32-bit value.  Sure we
>could use only the top two bits (00 for initial, 01 for reneg - it's after
>2004, so all times have MSB=1), but then you can't tell the difference
>between a patched TLS implementation and an implementation with its system
>clock not set properly.

... or an implementation that sees advertising your machine's clock skew to
the world as a security weakness (which it is when it starts interacting with
PKI) and sets the time field to a random value.

Peter.

v2.23.0 | Report a Bug | By Email