RE: [TLS] GSS based PSK-TLS

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

This will continue to work. I would like to emphasize FKA-TLS is a
variant of PSK-TLS.

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

you do not need to resume in the GSS level. You can resume in the
PSK-TLS level. Again, this is a variant of PSK-TLS, you have all the
bells and whistlers of PSK-TLS.

--larry

-----Original Message-----
From: Martin Rex [mailto:Martin.Rex@sap.com] 
Sent: Tuesday, July 17, 2007 2:42 PM
To: Larry Zhu
Cc: tls@ietf.org
Subject: Re: [TLS] GSS based PSK-TLS

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@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls