Re: [TLS] Proposed text for removing renegotiation

["[e-mail]" <[e-mail]>]

On 9 Jun 2014, at 20:17, Martin Thomson <[e-mail]> wrote:

> On 9 June 2014 00:34, Nikos Mavrogiannopoulos <[e-mail]> wrote:
>> Could somebody elaborate on what is that issue and why does it need to
>> be solved? (it is not even mentioned in the TLS 1.3 charter) As someone
>> who follows the mailing list that proposal comes out of the blue with no
>> context whatsoever.
> 
> 
> I think that this has been covered in the thread, but piecemeal:
> 
> * Renegotiation is a major source of security issues, both of the "we
> screwed the TLS design up" sort and of the "my application didn't
> realize that these things could change" sort.  There is a clear desire
> to remove features that enable either sort of problem.
> 
> * Renegotiation is just more protocol complexity.  Removing it
> potentially makes implementations simpler.
> 
> I think that either might be sufficient justification for removing the feature.
> 
> However, a number of use cases depend on renegotiation to achieve
> their ends.  Of these, we have identified:
> 
> * mid-session client authentication, which uses renegotiation seems to
> only be used in HTTP

As you know, but others may have missed, this is proving to be very useful
to create distributed authentication, which can be used for distributed 
access control, which is what is needed to create a distributed secure social
web, which is the best answer to problems Snowden revealed - which are inevitable
when centralised services amass huge amounts of data on a huge number of individuals.

In the WebID authentication over TLS spec as specified currently a server SHOULD 
use this renegotiation in order to provide a sensible user experience.

   http://www.w3.org/2005/Incubator/webid/spec/


The client side certificate features of TLS would be useless without reneg, because
a server would always have to ask for the identity of the user, even if the
user only asks for public resources.

So given that there is a feature in TLS that is in fact useful to increase
communication security by increasing secure p2p interaction on the most used protocol
in the world ( HTTP ), I think we need to make absolutely sure that the
removal of this feature is not going to remove the ability to do this distributed
authentication. Otherwise one could argue that removal of this feature could
be used to increase the surveillance state we are allready in (by removing a
key feature that would enaple secure p2p communication).

So I know there is http://tools.ietf.org/html/draft-thomson-tls-care-00
that could be deployed in conjunction with a "WWW-Authenticate: Certificate" HTTP headers 
to allow a client to ask the server that it be authenticated. [1]

But is draft-thomson-tls-care going to be part of TLS1.3? 
Are we absolutely sure this will work?

I'd say that one should not allow removal of TLS client renegotaiton unless one
can be very clear that this is so.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1039.html

> 
> * very long-lived connections, which require renegotiation to re-key
> occasionally
> 
> The former we have decided to solve in HTTP.  As a side note, we just
> decided to forbid renegotiation in HTTP/2.
> 
> The latter can be addressed by my proposal, or any of a number of mechanisms.
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls

Social Web Architect
http://bblfish.net/