Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

Peter Saint-Andre <stpeter@stpeter.im> Tue, 10 November 2009 21:08 UTC

Return-Path: <stpeter@stpeter.im>
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 AB9BE3A6B30 for <tls@core3.amsl.com>; Tue, 10 Nov 2009 13:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level:
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599]
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 RrgamxHeyU0b for <tls@core3.amsl.com>; Tue, 10 Nov 2009 13:08:43 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B5DF83A6B2F for <tls@ietf.org>; Tue, 10 Nov 2009 13:08:43 -0800 (PST)
Received: from host-113-169.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7CF9540D09; Tue, 10 Nov 2009 14:09:10 -0700 (MST)
Message-ID: <4AF9D674.6010500@stpeter.im>
Date: Wed, 11 Nov 2009 06:09:08 +0900
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> <20091109223417.GK1105@Sun.COM> <4AF8E755.5020208@extendedsubset.com> <20091110164609.GS1105@Sun.COM> <4AF9AA9E.8030603@extendedsubset.com> <20091110181544.GW1105@Sun.COM>
In-Reply-To: <20091110181544.GW1105@Sun.COM>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
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, 10 Nov 2009 21:08:44 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/11/09 3:15 AM, Nicolas Williams wrote:
> On Tue, Nov 10, 2009 at 12:02:06PM -0600, Marsh Ray wrote:
>> Nicolas Williams wrote:
>>> On Mon, Nov 09, 2009 at 10:08:53PM -0600, Marsh Ray wrote:
>>>
>>> TLS connections are not so long lived
>> But there is no defined upper limit.
> 
> True, and indeed, IMAP depends on that.  Are there IMAP/other servers
> the request re-negotiation when a client's cert reaches/nears
> expiration?
> 
> If so then my assertion that we don't have to worry about key rollover/
> cert expiration would be wrong.  Indeed, it's safer to assume that that
> assertion was wrong as finding out for sure would be hard.
> 
> However, this is a constraint that _applications_ could enforce, or
> request be enforced by the TLS implementation (oh dear, back to APIs).

IMHO this is the responsibility of the application. 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. I'll bring this up on the XMPP WG list...

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr51nQACgkQNL8k5A2w/vwTMgCdHDyyU/rnldyl27WEtBik6oTv
eKQAoNIY18NGdVOjSpEtpsTPWV49RhQc
=Rah7
-----END PGP SIGNATURE-----