Re: [TLS] TLS renegotiation issue

[Nicolas Williams <[e-mail]>]

On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote:
> I now have a draft extension up at:
> 
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

Initial comments based on a brief skim:

 - Please add a normative reference to RFC5056.

 - There's no real need for the ServerHello to include both of the
   Finished messages from the outer TLS connection.  (I think there's no
   real need for the ServerHello to include either of them, actually,
   but I've not thought enough about that.)  But it's OK as is, of
   course.

 - You call for each TLS handshake to bind to the one immediately
   outside it.

   Would it be better to bind to the outer-most one instead?

   (In practice there's probably never more than one outer and one inner
   handshake, right?)

 - There is a way for clients to protect themselves even when servers
   don't implement this extension:

   a) clients MUST NOT ever send any application-level messages without
      TLS protection if they are willing to negotiate a TLS connection
      after sending any application-level messages,

   _and_,

   b) if a server requests re-negotiation then the client MUST ensure
      that the outer and inner TLS connection handshakes used a server
      certificate, and, specifically, the _same_ server certificate,
      otherwise the client MUST abort without ever completing the
      second/inner handshake.

   This should be stated as it is a helpful workaround that works
   without modifying the protocol.  It's not a generic solution, and
   it's a client-side-only solution, which is why it's highly desirable
   to apply the proposed channel binding solution instead.

 - Might as well update RFC5246 to indicate that the Finished messages
   for any connection MUST be exported to applications.  Better get this
   done now.

Nico
--