IETF Logo Mail Archive

Re: [TLS] Next steps for draft-ietf-tls-renegotiation

Yoav Nir <ynir@checkpoint.com> Sun, 06 December 2009 21:04 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 8BB4C3A69C7 for <tls@core3.amsl.com>; Sun, 6 Dec 2009 13:04:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level:
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 0LHfgd9Tk+l0 for <tls@core3.amsl.com>; Sun, 6 Dec 2009 13:04:03 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 26EC03A69C9 for <tls@ietf.org>; Sun, 6 Dec 2009 13:03:46 -0800 (PST)
X-CheckPoint: {4B1C1BBF-10002-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BB96729C00D; Sun, 6 Dec 2009 23:03:35 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A4BAD29C002; Sun, 6 Dec 2009 23:03:35 +0200 (IST)
X-CheckPoint: {4B1C1BBE-10000-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 nB6L3YGo004109; Sun, 6 Dec 2009 23:03:35 +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; Sun, 6 Dec 2009 23:03:45 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "<Pasi.Eronen@nokia.com> <Pasi.Eronen@nokia.com>" <Pasi.Eronen@nokia.com>
Date: Sun, 06 Dec 2009 23:03:33 +0200
Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation
Thread-Index: Acp2t5jZgRWcBYYYSM6P+Elj4NpEVA==
Message-ID: <DC5451AB-B2C9-49AF-B153-A2DF552F6949@checkpoint.com>
References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <C7398D06.6CB8%stefan@aaa-sec.com> <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@NOK-EUMSG-01.mgdnok.nokia.com> <2D9C122C-23B4-4284-93B2-FFADF33798C4@checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F3128928A@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3128928A@NOK-EUMSG-01.mgdnok.nokia.com>
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] Next steps for 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: Sun, 06 Dec 2009 21:04:04 -0000

On Dec 4, 2009, at 3:29 PM, <Pasi.Eronen@nokia.com> <Pasi.Eronen@nokia.com> wrote:

> Yoav Nir wrote:
> 
>>> This surprised me a bit (but possibly the surprise is a positive
>>> one).  I would be interested in hearing from folks who've earlier
>>> opposed the use of extensions whether this reflects their current
>>> views, too.
>> 
>> I think there should be some form of extension-less signaling from
>> client to server, at least for SSLv3 and TLS 1.0 on the initial
>> handshake. 
> 
> The current draft has exactly this (as far as I can tell) -- so
> are you OK with that part (and agree that the remaining issue
> is sending-or-not-sending verify_data over-the-wire), or are
> you proposing changes to the signalling part, too? 
> 
> (From your other email on the same day, I got the impression
> you were not happy with the signalling part either...) 

I would like the signaling to be applicable in more situations (up to and including TLS 1.0 at least, even if the Client Hello is proposing an upgrade to TLS 1.2 or higher), but I agree that this should not delay publication as long as this is available when you begin with SSLv3.

v2.23.0 | Report a Bug | By Email