Re: [TLS] Proposed text for removing renegotiation

[Yoav Nir <[e-mail]>]

On May 28, 2014, at 8:47 AM, Brian Smith <[e-mail]> wrote:

> 
> On Tue, May 27, 2014 at 2:39 PM, Martin Thomson <[e-mail]> wrote:
> It's not possible to just remove renegotiation.
> 
> Why not? What is the motivation for keeping any form of renegotiation, even rekeying? It isn't clear from the public mailing list discussions what is motivating the rekeying feature. (Perhaps I overlooked something; if so, a link to the past decision on this would be appreciated.)
>  

Why not?  Because people are using it to accomplish things, and you can’t just pull it away without giving them some other way of doing what they’re doing, otherwise you get “TLS 1.3 is not suitable for long-lived connections” or “TLS 1.3 is not suitable for mutual authentication”.

With that in mind, in discussions on this list and at the interim meeting two uses for renegotiation were mentioned:

1. Client Authentication. For various UI reasons, web applications don’t want to send a certificate request on the landing page. They want the certificate authentication in response to a request for a protected resource, one that requires an authenticated client. This is not something that Google, Facebook or Tumblr use, but it’s much more common in SSL VPNs, corporate portals, and some banking web sites.  Martin has a couple of drafts for making this happen in a combination of HTTP authentication method (“go away and come back with a certificate”) and a TLS extension (“I have a certificate. Please send a CertReq”).

2. Connections that carry so much traffic and last so very long that you really need to rekey. This was discussed at the meeting, partially on Jabber ([1]). It’s not that common for the web, but I’m assured that XMPP connections sometimes last basically forever, so they need rekeying. My proposal there (at 19:40) was for this use case. Martin is right that it adds “dead air”, but all these use cases are not that delay sensitive, and I think it’s worth it to get the simplified state machine.

Yoav

[1] http://www.ietf.org/jabber/logs/tls/2014-05-16.html around 19:24