Subject: [TLS] Dealing with dead air (was Re: Call for Consensus on removal of renegotiation)

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jun 2014 13:41:10 -0700

On 25 June 2014 13:26, Colm MacCárthaigh <[email-masked]> wrote:
> Probably a stupid and ignorant question; but what prevents
> applications with this kind of requirement from creating a new
> connection, negotiating a new key, and then switching to the new
> connection when they're ready?

They can.  But that new connection will be subject to TCP slow start,
so it might take some time.

And then there are applications that accumulate state associated with
a connection, making it quite costly to move, since the state has to
be ported over.  In the worst case, this can be a deal breaker,
because the peer and the protocol aren't under client control - and
the client is the only entity able to force the creation of a new
connection.

At some level, you have to be willing to do this sort of thing in
order to deal with transient faults, but to be forced to do it
frequently is something else.  Often that fault recovery won't carry
all state forward, at least without extra engineering effort.
Exceptional circumstances and all that...

So it's not as simple as just making a new connection and using that.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 25 Jun 2014 14:15:35 -0700

> Exceptional circumstances and all that...

A MITM can introduce just those kinds of faults - so if the
application protocol isn't tolerant of that and it causes some kind of
DoS, it seems like it's a non-starter to begin with.

-- 
Colm