IETF Logo Mail Archive

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

Yoav Nir <ynir@checkpoint.com> Tue, 01 December 2009 10:17 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 C59B028C0DD for <tls@core3.amsl.com>; Tue, 1 Dec 2009 02:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.03
X-Spam-Level:
X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 jbjcHFVQ0iwH for <tls@core3.amsl.com>; Tue, 1 Dec 2009 02:17:32 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 87ECA3A683E for <tls@ietf.org>; Tue, 1 Dec 2009 02:17:31 -0800 (PST)
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 nB1AHGGo027786; Tue, 1 Dec 2009 12:17:16 +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; Tue, 1 Dec 2009 12:17:23 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "<Pasi.Eronen@nokia.com> <Pasi.Eronen@nokia.com>" <Pasi.Eronen@nokia.com>
Date: Tue, 01 Dec 2009 12:17:14 +0200
Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation
Thread-Index: Acpyb3kNprPvwWFQQHmegQWsADJVqg==
Message-ID: <2D9C122C-23B4-4284-93B2-FFADF33798C4@checkpoint.com>
References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <C7398D06.6CB8%stefan@aaa-sec.com> <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@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: Tue, 01 Dec 2009 10:17:32 -0000

On Nov 30, 2009, at 10:38 PM, <Pasi.Eronen@nokia.com> <Pasi.Eronen@nokia.com> wrote:

> <wearing Area Director hat>

<snip/>

> 
>> As you say, no approach today is totally extension less, so the big
>> difference remaining IMO is:
>> 
>> 1) The fail-unsafe approach based on sending verify_data in extensions.
>> 
>> 2) The Fail-safe approach based on injecting varify_data into the
>> handshake hash calculation, but not sending them over the
>> wire. (This approach uses extensions for signaling but with absent
>> data)
>> 
>> Everything else is more or less the same.
> 
> 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. I also think that it's a good idea to have some kind of server to client signaling to show that no renegotiations are supported, but servers that support the new, safe renegotiation should reply with an extension. Since the client proposed it in the magic ciphersuite, the response extension is not unsolicited. 

> If it does, I think we've made a lot of progress, and can still tweak
> the final difference (whether to send verify_data over-the-wire or not) 
> based on discussion during the IETF last call.
> 
> I do not claim that a large majority currently strongly prefers
> sending the old verify_data over-the-wire in the extension data. Much
> smaller number of people (compared to the signalling issue) have
> expressed any opinions about this, and also, I would expect that a
> smaller number of people care very strongly either way.

The signaling issue may harm connectivity, and that's a hot button issue. verify_data over the wire has not-well-understood security implications, and is mostly an implementation detail, so it generates less fervor.

Still, I believe that anything that makes it harder for implementers to mess up on security is a good thing, so I do care very strongly about it.

> 
> And BTW, in this question I agree that counting opinions expressed
> much more than a week ago probably isn't that good. So if someone
> (any reader of this message) cares very strongly either way, 
> I would suggest saying so on the list (if you haven't done so
> already recently).

Just did.

Yoav

v2.23.0 | Report a Bug | By Email