Subject: [xmpp] [Fwd: Re: [TLS] RC4+3DES rekeying - long-lived TLS connections]

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 22 Nov 2009 11:42:33 -0700

FYI from the TLS WG list.

-------- Original Message --------
Subject: Re: [TLS] RC4+3DES rekeying - long-lived TLS connections
Date: Sun, 22 Nov 2009 11:38:35 -0700
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
CC: [email-masked]
References: <[email-masked]>

On 11/20/09 11:28 AM, Martin Rex wrote:
> 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).

Thanks for the tip. We'll do some research about this in the XMPP WG.

> 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.

That's why draft-ietf-xmpp-3920bis-04 (section 14.2.2.3) talks about the
need to (1) close the stream if the expiration date occurs during the
life of the stream and (2) periodically check the OCSP responder.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/