Re: [TLS] Negotiation in draft-santesson-tls-gssapi

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

Martin Rex wrote:
> 
> > Comparing Martin's rough proposal, the current ID optimizes for the
> > minimal # of roundtrips and gives us more a more generic and more
> > extensible solution. 
> 
> If you coalesce the first GSS-API context establishment roundtrip
> onto the TLS finished messages you have the same amount of roundtrips
> for a TLS+rfc-1964 kerberos authentication than for a plain TLS
> handshake.   
> 
> Did I miss a clever roundtrip reduction of the TLS handshake
> in the current ID, or could there be an error in your counting?

Rechecking the spec and OpenSSL, I realize that, although such
an optimization should be technically possible, it would somewhat bent the
TLS existing handshake and require quite non-trivial changes to the
TLS state machine and semantics of SSL_connect when trying to implement
the gssapi-over-tls authentication with inital context token coalesced
to the TLS finished messages in an entirely seperate code layer
"TLSplus" above TLS.

I notice, however, that I still consider the necessary contortions
to run the entire GSS-API context establishment within TLS and
the TLS handshake according to the current ID _MAGNITUDES_ worse
if one also wants to make use of all the various GSS-API
features and extensions.


For cached&resumed SSL sessions, there are no additonal roundtrips
in either case (just the unexplained dirty hacks for the current ID
in order to get access to GSS-API attributes of the original
full SSL handshake).

Personally, I do not consider the additional roundtrips of the
GSS-API context establishment a showstopper.  The overhead of
rfc4559 Negotiate is worse (in particular with IIS6 as a backend!),
and still it is surprisingly usable--well, at least with a sane
backend that issues a secure session id upon inital rfc4559
authentication and does not constantly throw 401 Unauthorized
for each and every request on an established TLS-protected
communication channel.  That IIS6 curiosity reliably prevents
pipelining of requests.  

Because of this, I can easily understand that Microsoft has a significant
performance issue with their deployed software using rfc4559.
But frankly, I strongly doubt that one additional roundtrip on
a full SSL handshake is going to be performance killer.
As I mentioned before, when I was involved in Analyis of Performance
issues with HTTPS-protected communication in High-end installations
of our software, the only time when the SSL handshake became an
issue was when the server SSL session cache size was too small
leading to a 50:1 ratio in full handshakes vs. session resumes
compared to a 1:30 ration in full handshakes vs. session resumes
on new network connetions with a sufficiently large session cache size.  

-Martin

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