FYI from the TLS WG list. The need to periodically modify the list of mandatory-to-implement cipher suites might argue for splitting the MTI list into a separate document, as previously discussed here. /psa -------- Original Message -------- Subject: Re: [TLS] RC4+3DES rekeying - long-lived TLS connections Date: Sat, 21 Nov 2009 04:06:21 +0000 From: David-Sarah Hopwood <david-sarah at jacaranda.org> To: tls at ietf.org References: <200911201828.nAKISN6Y017007 at fs4113.wdf.sap.corp> 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). As far as I know, RC4 as used in TLS does not have a significant problem with encrypting large amounts of data. There are small statistical biases in the RC4 keystream but they're not a serious threat in most situations. If you're worried about the information leakage in using 3DES for long-lived connections, then it's probably a better option to disable 3DES ciphersuites, than to use renegotiation to rekey. I think that disabling 3DES should not cause significant interoperability problems provided you continue to offer both RC4 and AES ciphersuites. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com -- Peter Saint-Andre https://stpeter.im/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.