Re: [TLS] tls 1.3: renegotiation

I agree with Robert, and oppose removal of renegotiation for the reasons listed. 

Also, the removal of renegotiation will complicate the deployment of TLS1.3 and limit its applicability. E.g. it is not clear to me how these configurations would work (when TLS client auth is required):
1. TLS 1.3 with an existing HTTP/1.1 server;
2. Existing TLS 1.2 library with HTTP/2 stack on top of it.

It looks like one would need to deploy  both TLS1.3 and HTTP/2 at the same time. Once TLS 1.3 and HTTP/2 are deployed, the way a site implements TLS client auth will depend on the combination of TLS version and HTTP version negotiated:
TLS1.3 + HTTP/2 -> New-style TLS client auth (TBD).
TLS1.3 + HTTP/1.1 -> No way to support TLS client auth?
TLS1.2 + HTTP/2 -> No way to support TLS client auth?
TLS1.2 + HTTP/1.1 -> TLS client auth via renegotiation.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Robert Ransom
Sent: Friday, July 25, 2014 12:28 PM
To: Sean Turner
Cc: TLS@ietf.org (tls@ietf.org)
Subject: Re: [TLS] tls 1.3: renegotiation

On 7/21/14, Sean Turner <TurnerS@ieca.com> wrote:
> At the TLS interim meeting held on Sunday July 20th, 2014, there was 
> consensus to remove renegotiation on the assumption we will provide a 
> rekeying facility of some form and client initated client authentication.
> This message serves to confirm that consensus.  Please indicate by 
> July 25th, 2014 whether you disagree with this (and why).

I oppose removal of renegotiation, for the following reasons:

* Renegotiation is a single feature which serves many purposes.  I
  believe that fixing the design, APIs, and implementations of
  renegotiation will be easier than designing the protocols, designing
  the APIs, and implementing every feature which would be needed to
  replace it.

* The client-initiated client authentication feature will require a
  ‘channel binding’ to the existing TLS connection, which -- as Nico
  Williams has pointed out -- is sufficient to work around
  renegotiation-based attacks at the protocol level, by binding the
  application data sent before renegotiation to the authentication
  performed during the renegotiation handshake.  Adding a channel
  binding to renegotiation would not require as many changes to
  existing code as adding an entirely new client authentication
  feature would, and would provide less room for new implementation
  bugs to creep in.

* Renegotiation can share most of its code with the implementation of
  the initial connection handshake, even after a channel binding is
  added to it.  Each of the new features added in order to replace
  renegotiation is likely to share considerably less code with the
  initial handshake, and their implementations are likely to receive
  considerably less use and less testing than any piece of code used
  in implementing renegotiation.

In addition, I believe that it is not possible for the WG to make an informed decision as to whether renegotiation should be removed at this time:

* The rekeying feature and client-initiated client authentication
  feature have not been specified yet, even to the point of stating
  the requirements which each feature will meet.  It is not possible
  for the WG to determine whether the features intended to replace
  these two uses of renegotiation will be fit for their intended
  purposes at this time.

Robert Ransom

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls