IETF Logo Mail Archive

Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

Badra <badra@isima.fr> Tue, 15 December 2009 12:01 UTC

Return-Path: <mbadra@gmail.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 0A1523A69C6 for <tls@core3.amsl.com>; Tue, 15 Dec 2009 04:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 AdAoZw5eU8Lw for <tls@core3.amsl.com>; Tue, 15 Dec 2009 04:01:05 -0800 (PST)
Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id A3E4C3A69BF for <tls@ietf.org>; Tue, 15 Dec 2009 04:01:04 -0800 (PST)
Received: by fxm7 with SMTP id 7so4076263fxm.29 for <tls@ietf.org>; Tue, 15 Dec 2009 04:00:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=RshMRsRfRpOqZoRY9ocT77Pji5QAaKUe85BYoCQN5F4=; b=PPjhweXKDsuwD1aKR/x+7X+ciBPVRUVSjHpf0qT5JlaQ1TU+KksBzgf4MTBKjpcHee 5iuQh11amU2GRPdj2rro3NrpGqx3XLvPXLQL4WkGvTwWuzWzW7WkEjHWK8NvMy/aJgek Og4Hopo8vA+od7Qtrbj9szYfrOAcAT6/Qu+wE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=l5wvdTN+fiXuvzxwar/rrPDsocx3dLyLm1sG/9giUviKpzCpc7dl3C89NwmQyGfypv RRUkDzzFOnFtyW7CmWT/x0wTTSejFct51QpUau3ML3TlMMjLQgaPBL4jcPlyObIfxD3x v0h8D1c/HDb4qV8ziofLyd+PKOgXz0hr8BOGc=
MIME-Version: 1.0
Sender: mbadra@gmail.com
Received: by 10.239.145.129 with SMTP id s1mr622931hba.45.1260878446908; Tue, 15 Dec 2009 04:00:46 -0800 (PST)
In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402D31A78@XCH57YKF.rim.net>
References: <20091214191959.427A53A6A27@core3.amsl.com> <20091214194431.GO1516@Sun.COM> <7E1DF37F1F42AB4E877E492C308E6AC402D31A78@XCH57YKF.rim.net>
Date: Tue, 15 Dec 2009 16:00:46 +0400
X-Google-Sender-Auth: 6c11d985521caace
Message-ID: <c24c21d80912150400v49633ef4hc66f4aceb680c871@mail.gmail.com>
From: Badra <badra@isima.fr>
To: Robert Dugal <rdugal@certicom.com>
Content-Type: multipart/alternative; boundary="0016e654fe6eeed5a7047ac3235b"
Cc: tls@ietf.org
Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 12:01:06 -0000

On Tue, Dec 15, 2009 at 3:46 PM, Robert Dugal <rdugal@certicom.com> wrote:

> The server based gaming specs require renegotiation periodically in order
> to refresh TLS session keys.
>

What about resumed handshake? you don't need a new handshake to refresh your
keys

Best regards
Badra

On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote:
> >   As a protocol climbs the IETF standards-track maturity ladder, we
> >   sometimes drop features.  I would rather see renegotiation dropped
> >   from TLS than see this complexity added to TLS protocol.
>
> I would like to agree.  There's no real-world need to re-negotiate for
> re-keying nowadays: with the advent of 128-bit block block ciphers
> there's little need.
>
> But re-negotiation remains useful for other purposes.  Probably the most
> obvious ones are optional authentication and privacy protection for
> client credentials.  I'm not sure those are sufficiently useful or
> important to warrant keeping the feature, but if not then dropping the
> feature does seem like a better option than fixing it.
>
> Nico
> --
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email