[TLS] draft-rescorla-tls-renegotiate.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TLS] draft-rescorla-tls-renegotiate.txt



Eric Rescorla wrote:
> 
> >  4.1  Client Considerations
> >
> > 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.
> 
> I'm not recommending that clients do that. What I'm trying to say is that
> *if* a client wants to be totally sure then all it can do is require
> the extension.
> I agree it's impractical (and probably unwise) to suggest that they actually
> behave that way.
> 
> Do you agree that the characterization above is correct? If so, how can I
> update the draft to make that clearer?

Yes, unfortunately, the description is the honest and cold truth.

It's challenging to come up with something better.

Maybe the consequences of the suggestion to no longer talk to
SSL/TLS servers without that extension should be made more
explicit.


As correctly described in Marshs publication, the problem affects
all existing releases of the SSL and TLS protocol family.

I assume that this WG, the IETF, the vendors and the consumers would
appreciate if the fix could be applied to the entire installed base,
no matter what protocol level each component implements.

It's not always an option to move to a newer implementation that
also supports a more recent version of TLS, so I would appreciate
that we describe two additional things in this draft:

   - to describe how to add/implement this fix to each and
     every affected protocol version of the SSL/TLS Family.

     I just noticed that SSLv3 does _NOT_ have a "no_renegotiate" alert!
     To me, it looks like the SSLv3 spec does not specify how to
     deny performing a renegotiate.  Which is slightly odd, since
     there are SSLv3 implementations that do not implement renegotiation...

   - to describe/suggest the behaviour for implementations of SSL/TLS
     that do not support (or do not want to perform) renegotiation,
     in particular for SSLv3.

   - since we currently overload the empty extension with signaling
     to different things: 
       - I am a patched server
       - I support secure renegotiation

     we should probably explicitly describe what a TLS v1.x Server
     should do if it does not implement TLS renego in the server or
     reliably know that it will not perform renegotiation.
     Since it is against common sense that such a server responds
     with a TLS Extension "I support secure renegotiation" in
     the ServerHello, we should explicity write what we want them
     to implement.


-Martin


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.