Re: [TLS] Comments on TLS identity protection

> When the server-requested renegotiation is application triggered,
> as in the Microsoft IIS case, then the server better caches the
> result along with the SSL session.
>
> Microsoft IIS has a silly (performance-wasting) bug, where a client that
> does either not have a client cert or does not show one (and requiring
> the application to perform application level client authentication)
> is continously forced through the renegotiation when the client
> tries to resume the session from the session cache on a new connection.

This is not a bug. It is an explicitly permitted state within the SSL v3 
conformance/state. Upon request, a client MAY send a client cert. What 
happens if it doesn't, is server policy.

The handshake protocol affects session state. Session resumption (a poorly 
named procedure) affects connection state, only.

Where a client cert is used for user auth purpose(in e.g. https) we have a 
situation that is different to a client cert being used to merely 
authenticate an T-connect peer. Whether the user app intended a previous 
user auth to be applied to a new connection is not specified in the 
"designers" rendition of the https protocol. That is, its up to the 
implementation of https, by intent. The implementation of Netscape-https is 
very different to that of IE-https (and MSFT's wininet.dll's default 
https,for wininet consumers that are not IE)

By definition http over SSL is https. Nothing more is stated. each https 
designer specifies their own "usage profile". Netscape-browsers have their 
concept for sharing hypermedia-state across TLSconnections, client side, and 
assured OS have theirs. Its that simple. There is no right or wrong, bug or 
not-bug.

>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
> 

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