[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 []) 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-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 ([]) by localhost (core3.amsl.com []) (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 []) 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.


PS: WinXP and Win2K3 do not support AES ciphersuites.
    Btw. WinXP was shipped with new NetBooks well into 2009.