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

[Martin Rex <mrex at sap.com>]

Martin Rex wrote:
> 
> 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:

While the things just described do not (necessarily) change the
proposed wire-protocol, they might change semantics and
interoperability of the protocol exchange with ongoing
implementations.  Making handshakes with attackers fail
earlier during the handshake is not my concern, of course.

But aside from this proposal, I was never really happy with
the performance impact of the delayed client auth, because
a TLS renegotiation alwas incurs a full TLS handshake.

There used to be (I have not checked lately) a particularly
bad user experience when connecting a firefox (2.x) to
MS IIS6 on W2K3 configured in directory-level access permissions
(i.e. the configuration that results in delayed TLS client auth
 through renegotiation).  When MS IIS6 was configured to allow
client-cert based authentication plus HTTP-authenticate:Negotiate
or basic-auth, but the firefox browser did not have a client
cert (or the user did not want to send it), then the bug in
the MS IIS6 server-side session cache resulted in a renegotiation
on every new connection, which resulted in a certificate selection
popup.  This could result in several popups per page if you
were browsing regular web-pages in protected areas rather
than plain directories.

What I would have appreciated, and what could prevent this
nonsense, is an extension that signals from the client to
the server "You do not need to try a CertificateRequest on me,
I will not send you a certificate!".  If a browsers memorizes
the uses decision (to not send a cert, or that there is no cert),
then it would really help if it could tell this to the SSL/TLS
server right away, instead of requiring the server to wonder
and probe this information with a full blown TLS handshake
through TLS renegotiate.


I do _not_ want to get any improvement in this area get into
the way of fixing the "secure renegotiation" issue.

Well only if the implementors/vendors that are most affected
by the security problem propose/agree that we could add
such signalling here (plus TLS WG consensus, of course).


-Martin