Re: [TLS] TLS renegotiation issue

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> I now have a draft extension up 

Thanks Eric.

  Page 5:

  The contents of this extension are specified as follows.
   [...]
  The above rules apply even when TLS resumption is used.


I read this as meaning that the client and server should add
two elements client.verify_data and server.verify_data
to their SecurityParameters for the connection state suggested
by RFC5246 6.1. and update this data on EVERY TLS handshake,
even TLS session resume.


  4.1  Client Considerations

I can understand what it says, but I _really_ dislike it.

The root of the problem is servers that perform (or at least allow)
TLS renegotiations and make flawed assumptions about what a
successful TLS renegotiation means for the data previously received.

What you're essentially asking for, is that a client should no longer
talk TLS to _any_ Server that doesn't support the new extension.
Not even to the good ones that neither offer nor support renegotiation.

This is discriminating against servers that have been playing safe!

Essentially we are going to hold TLS clients and the installed
base of good Servers responsible for the broken Servers out there.
That feels very wrong.


-Martin

PS:

>
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

That URL results in a cert warning in my Firefox browser.
Following the Client considerations, I feel much safer
removing the "s" in "https" in the URL than trying to add
an exception for the servers certificate...  ;-)