[TLS] RC4+3DES rekeying - long-lived TLS connections
Martin Rex <mrex@sap.com> Fri, 20 November 2009 18:28 UTC
Return-Path: <mrex@sap.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 99B603A6919 for <tls@core3.amsl.com>; Fri, 20 Nov 2009 10:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.078
X-Spam-Level:
X-Spam-Status: No, score=-6.078 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 1s9-YUZcSu2X for <tls@core3.amsl.com>; Fri, 20 Nov 2009 10:28:46 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 857133A68DD for <tls@ietf.org>; Fri, 20 Nov 2009 10:28:46 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAKISOLD016112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 19:28:24 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911201828.nAKISN6Y017007@fs4113.wdf.sap.corp>
To: stpeter@stpeter.im
Date: Fri, 20 Nov 2009 19:28:23 +0100
In-Reply-To: <4AF9D674.6010500@stpeter.im> from "Peter Saint-Andre" at Nov 11, 9 06:09:08 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: [TLS] RC4+3DES rekeying - long-lived TLS connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 20 Nov 2009 18:28:47 -0000
Peter Saint-Andre wrote: > > ... For example in XMPP > we use long-lived TCP connections and, on top of those, long-lived XML > streams that can be TLS-protected. In practice, for server-to-server > federation (and even for client-to-server communication) those > connections might be up for days, weeks, even months. At this point the > handling of long-lived XML streams is unspecified, but I would expect > most XMPP servers to terminate the connection and force the other party > to reconnect. There was a discussion around long-lived SSL connections and reasons for rekeying, e.g. using TLS renegotiation on mogul-open. If you're using ciphersuites with RC4 or 3DES encryption algorithms, you probably should not use such connections for prolonged times or huge amounts of data without rekeying (see below). The other issue: if you're authenticating such a connection once based on X.509 certificates and leave it open for month, you might want to talk to the PKIX folks about this. They might feel uneasy if you happily continue to communicate based on an authentication that was weeks or months in the past and do not care at all the authentication cert may have long expired or been revoked in the meantime. (I'm not a crypto-guy, so I'm just quoting this:) : Subject: Re: DES & renegotiation : Date: Thu, 19 Nov 2009 17:08:36 -0800 : From: Geoff Keating <geoffk@apple.com> : : : For an 64-bit block cipher, at 2^32 blocks (32Gbytes), there's about a : 40% chance of a collision. If you prefer your cryptosystems to have : more like a 1-in-a-million chance of leaking information, you'd need to : re-key every 48Mbytes or so. (For 128-bit blocks a 1-in-a-million : chance requires petabytes of data.) : : Most web servers on the visible Internet do support AES; in fact, well : over half support TLS_DHE_RSA_WITH_AES_256_CBC_SHA (although among the : most popular servers, the non-DHE AES variants are chosen more often). : When asking servers to negotiate a cipher out of a fairly long list, : I found: : : 71% AES : 25% RC4 : 4% 3DES : (values add to 100% only because of rounding) : : A quick survey of 30 randomly-chosen servers that chose 3DES indicated : that most were running Apache 1.3.x with a variety of older OpenSSL : versions, the most recent being 0.9.6i. A few were running IIS/6.0. -Martin PS: WinXP and Win2K3 do not support AES ciphersuites. Btw. WinXP was shipped with new NetBooks well into 2009.
- [TLS] draft-rescorla-tls-renegotiate and MITM res… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Dr Stephen Henson
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Steve Dispensa
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Peter Saint-Andre
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] To API or not Bill Frantz
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- [TLS] RC4+3DES rekeying - long-lived TLS connecti… Martin Rex
- Re: [TLS] RC4+3DES rekeying - long-lived TLS conn… David-Sarah Hopwood
- Re: [TLS] RC4+3DES rekeying - long-lived TLS conn… Peter Saint-Andre