Re: [TLS] GSS based PSK-TLS

[Martin Rex <Martin.Rex at sap.com>]

Larry Zhu wrote:
> 
> We would like to request for comments for the GSS based PSK-TLS ID:
> 
> http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt
> 
> 2) Why the GSS handshake does not come after the key exchange message?
> 
> We do not want to pay for the cost of the DHE or RSA in this case. 
> The main motivation for us is to enable Kerberos to secure TLS
> connections. 
> Kerberos is a lot faster, and we intend to keep it that way.

TLS session can be cached, resumed and forked.  Although performance
is an issue for a significant amount of our customers, the
RSA-server-authentication in the SSL handshake is NOT normally
an issue (it only becomes an issue if the SSL session cache is
configured too small).  So-called SSL Accellerators have a really
hard time to provide a benefit.  They might add latency and an
additional point of failures, and can hardly keep up with x86-based
multi-cpu multi-core machines (both in terms of price and performance).


GSS-API security context can not be cached and not be resumed.

A while ago I looked with HTTPWatch at the messages exchanged
between MSIE6 and IIS6 using HTTPS+Negotiate.  IIS6 forces
the client with 401 Unauthorized through a full new Kerberos
authentication with each and every request on an established
TLS channel.  I'm not impressed, and will not easily buy
"proposed solutions" for Microsoft-asserted performance issues.


And why is TLS authentication performance made a non-issue
for StartTLS vs FastArmor and a big issue here?


-Martin

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