Subject: Re: [TLS] Proposed text for removing renegotiation

From: "[email-masked]" <[email-masked]>
Date: Wed, 2 Jul 2014 19:08:25 +0200

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

> On 9 June 2014 00:34, Nikos Mavrogiannopoulos <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

Social Web Architect
http://bblfish.net/

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 2 Jul 2014 19:48:04 +0200

On 17 Jun 2014, at 22:56, Daniel Kahn Gillmor <[email-masked]> wrote:

> 
> But I suspect most application developers who use TLS don't understand
> that the authentication state or cryptographic protections of the
> connection may change mid-stream.  Of the minority that does understand
> that this state may change, i suspect that many of them don't actually
> handle the situation well (if at all).
> 
> if we want to avoid this on the implementation side, do we need more
> guidance to implementers of TLS stacks?  or guidance for
> application-layer users of those stacks?  or both?

Take this as someone who has come from Java land and has recently moved to Scala-land.
In Java in 1995 the aim was to make APIs very easy to use, for developers used to
thinking in single threaded manners. But currently with the deployment of
multi-core cpus ( Eg. Sun Microsystems T5 with 16 cores and 8 threads per
core for a total of 128 threads, which in an 8 socket system can lead to 
1024 thread system ) and the growth of web apis, functional programming languages 
such as Scala are coming to the fore. Very good libraries are being developped there such
as the actor framework at https://akka.io/ with very good marketing for
concepts such as reactive programming ( http://www.reactivemanifesto.org/ )
and Reactive Streams ( http://spray.io/scaladays2014/ ) which is making it
much easier to code such mid-stream changes, and to think about these issues.

In the past few years of programming in this space I have learned more than
I had in the previous 10 years of programming. In short: programming has become 
enjoyable again, and in great part due to the development of these frameworks.

I just thought I'd mention that, as what may have been difficult 10 years ago,
has perhaps now become easy. So such implementor guidance should take into
account these changes.

All the best,

	Henry Story

PS. a bit of background on me:
   http://www.australianscience.com.au/interviews/henry-story-a-social-web-architect/

Social Web Architect
http://bblfish.net/