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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Nov 2009 06:09:43 +0900

FYI from the TLS list...

- -------- Original Message --------
Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
Date: Wed, 11 Nov 2009 06:09:08 +0900
From: Peter Saint-Andre <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: [email-masked]
References:
<[email-masked]>
<[email-masked]>
<[email-masked]>	<[email-masked]>
<[email-masked]>	<[email-masked]>
<[email-masked]>

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

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 11 Nov 2009 09:15:27 +0100 (CET)

On Wed, 11 Nov 2009, Peter Saint-Andre wrote:
[snip]
> to reconnect. I'll bring this up on the XMPP WG list...

I don't think this is what is usually done. The certificate is checked
once - XEP 0178 s2s step 7 - and the authorization persists until the
stream is closed.

If the receiving server closes the stream and the originating server
reestablishes the stream, (starttls+)dialback might be used for
authorization (it would be sensible to completly reject expired
certificates, but that is not done in practice).

philipp

---

From: Sean Turner <[email-masked]>
Date: Thu, 12 Nov 2009 10:26:15 +0900

> to reconnect. I'll bring this up on the XMPP WG list...

One of the things we talked about was possibly checking an OCSP server
for revocation information periodically during a long-lived session.
This will only work if we a) manually configure servers to know where to
look for the OCSP responder b) we put a Authority Information Access
(AIA) extension in the server's certificate (points to the location of
the OCSP responder).  I poked around and see that some SSL/TLS
certificates include AIA so option b seems plausible.

spt

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Nov 2009 10:31:09 +0900

> certificates include AIA so option b seems plausible.

Yes. I know that the XMPP ICA (with the StartCom root) supports the AIA
extension, and IMHO that should be a best practice or even a SHOULD for
PKCs issued to XMPP entities, precisely because XMPP streams can live
for so long.

Peter

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