IETF Logo Mail Archive

Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

Yoav Nir <ynir@checkpoint.com> Mon, 14 December 2009 20:38 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 DD6D03A68A7 for <tls@core3.amsl.com>; Mon, 14 Dec 2009 12:38:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level:
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 hUF9t6bSdXHP for <tls@core3.amsl.com>; Mon, 14 Dec 2009 12:38:29 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E54703A63EC for <tls@ietf.org>; Mon, 14 Dec 2009 12:38:28 -0800 (PST)
X-CheckPoint: {4B26A173-10003-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1AA8A29C004; Mon, 14 Dec 2009 22:38:15 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 03CDE29C002; Mon, 14 Dec 2009 22:38:15 +0200 (IST)
X-CheckPoint: {4B26A172-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBEKcET7018424; Mon, 14 Dec 2009 22:38:14 +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; Mon, 14 Dec 2009 22:38:25 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Sebastian Gajek <gajek@post.tau.ac.il>, "tls@ietf.org" <tls@ietf.org>
Date: Mon, 14 Dec 2009 22:35:54 +0200
Thread-Topic: Closing some open comments on draft-ietf-tls-renegotiation
Thread-Index: Acp80/0d4zm97OCPEkiT1QBeYxZnuQAKQs+1
Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EC523@il-ex01.ad.checkpoint.com>
References: <C74C296E.63A%gajek@post.tau.ac.il>
In-Reply-To: <C74C296E.63A%gajek@post.tau.ac.il>
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
Subject: Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation
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: Mon, 14 Dec 2009 20:38:31 -0000

It would be easy to require this, but it's not compliant with the current spec. The current spec says that the finished value depends on all the bytes starting with the first byte of the ClientHello.

We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but adding the previous finished message is a change to the spec, one that requires some sort of signaling, either with a fake cipher suite or with an extension.

________________________________________
From: tls-bounces@ietf.org [tls-bounces@ietf.org] On Behalf Of Sebastian Gajek [gajek@post.tau.ac.il]
Sent: Monday, December 14, 2009 17:42
To: tls@ietf.org
Subject: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

Hi there,

sorry for putting another mail into the long list of TLS renegotiation
mails. I skimmed the TLS-renegotiation draft. Surely, a countermeasure is to
cryptographically link the TLS sessions. There are different approaches to
achieve this goal. I was wondering why you introduce a new cipher suite.
Wouldn't it be easier to require that finished values are a function of all
values received so far (incl. previous TLS sessions or at least their
finished values.) This countermeasure is simple, complies with the present
TLS spec and could result in faster adaption.

Is there a technicality I am not aware?

Thx for any feedback.

v2.28.0 | Report a Bug | By Email | System Status