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

Yoav Nir <ynir@checkpoint.com> Wed, 11 November 2009 20:28 UTC

Return-Path: <ynir@checkpoint.com>
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 0DC583A6AF9 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 12:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GJDgQQdV45x9 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 12:28:56 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 429C43A6806 for <tls@ietf.org>; Wed, 11 Nov 2009 12:28:33 -0800 (PST)
X-CheckPoint: {4AFB1B66-2-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 39EF029C00B; Wed, 11 Nov 2009 22:29:01 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1A35029C002; Wed, 11 Nov 2009 22:29:01 +0200 (IST)
X-CheckPoint: {4AFB1B65-2-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nABKT0c6017524; Wed, 11 Nov 2009 22:29:00 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 11 Nov 2009 22:29:02 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "mrex@sap.com" <mrex@sap.com>, Marsh Ray <marsh@extendedsubset.com>
Date: Wed, 11 Nov 2009 22:25:09 +0200
Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3
Thread-Index: AcpjC7BpmLuhuu2eQBKuTOIMKn6fQgAAV/mj
Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB4@il-ex01.ad.checkpoint.com>
References: <4AFB154A.9030106@extendedsubset.com> from "Marsh Ray" at Nov 11, 9 01:49:30 pm, <200911112015.nABKF68b018491@fs4113.wdf.sap.corp>
In-Reply-To: <200911112015.nABKF68b018491@fs4113.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <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: Wed, 11 Nov 2009 20:28:57 -0000

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.

A 32-bit magic value (the date of the first chartering of the TLS WG and the date of the vulnerability being published?) will reduce the likelihood of error to negligible. Two bits won't


________________________________________
From: tls-bounces@ietf.org [tls-bounces@ietf.org] On Behalf Of Martin Rex [mrex@sap.com]
Sent: Wednesday, November 11, 2009 22:15
To: Marsh Ray
Cc: tls@ietf.org
Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

Marsh Ray wrote:
>
> Yair Elharrar wrote:
> > Martin Rex wrote:
> >
> > It would probably be better if the entire 32-bit gmt_unix_time was
> > set to one of two predefined magic values:
>
> Do you know that nothing cares about the actual time encoded?
>
> Why burn 32 bits of entropy to represent one bit?

Yair's suggestion is actually 3 states (~1.5 bits)
   initial, renegotiation, unknown

but other than that, it also seems like waste to me to re-purpose
the _entire_ 32-bits.