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

[Martin Rex <mrex at sap.com>]

Nicolas Williams wrote:
> 
> Marsh Ray wrote:
> >
> > Nicolas Williams 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?

There is only a suggestion in the TLS spec that a TLS session ID should
not be valid for more than 24 hours.  That refers to the TLS session
cache and the possibility to resume a TLS session, not for the
lifetime of an established TLS session.

Busy Web-Servers may use significantly shorter session cache lifetimes
(our default is 15 minutes).

TLS connection lifetimes and session lifetimes, in particular for SSL-VPNs
that Steve mentioned, might be much longer.


But keep in mind, that issuer of credentials (like CAs) may have
a problem if an authenticated session can be held for several days
even though the credential may have long be expired, revoked or
the ACL may have been updated in the interim.

An application that depends on an authentication to be valid for
several days or weeks is probably a security problem all by itself.


How about recommending two recommendations instead of one:

 - TLS implementations should, by default, lock down identities during
   session renegotiation once they have been established in a TLS
   handshake, i.e. the implementation should ensure they match exactly
   (e.g. memcmp() of the certificate blob).  Identities not previously
   established in a TLS handshake can be established in a renegotiation
   for the first time.

 - TLS implementations are encouraged to offer an API to the applications
   where an application can request permission for a change in
   identities during renegotiation.  Application protocols that need
   this functionality, MUST specify the procedure how to perform
   authentication of the peer and the semantics of a change in
   identity during renegotiation.  TLS implementations must
   provide a signaling facility to such applications to distinguish
   application data received over the original TLS session from
   application data received over the newly renegotiated TLS session.


> 
> I suppose non-anon->anon re-negotiation, but with the new inner->outer
> connection binding should be OK once too (to allow for re-keying without
> having to bother with authentication).

I do not like that idea.

If renegotiation is performed and the identity is maintained, this
can be detected with a memcmp() on the certificate blob, and then
one can skip that authentication.

If the identity changes, a re-authentication ought to be performed.

Usually the issuer of a certificate assumes that it can no longer
be used once it is expired, but if you allow renegotiations to


Renegotiation creates a new session, that servers will usually add to
their session caches.  If such a session is resumed from the cache
on a new connection, you can _not_ perform an authentication.


-Martin