In message <43F8FE0F(_dot_)3060309(_at_)dcrocker(_dot_)net>, Dave Crocker
writes:
Folks,
Eric said:
1. It is slower because it requires two handshakes.
2. The client may have to authenticate twice (this is a special
case of (1)).
The second case can be easily ameliorated by having the client send an
extension (empty UME?) in the first handshake as a signal that it wants
to do UMDL and that the server should hold off on demanding client
authentication until the rehandshake happens.
The performance issue is quite modest with modern servers. Indeed, it's
quite common for web servers to do a first handshake without cert-based
client auth and then rehandshake with client auth if the client asks for
a sensitive page.
This raised a flag with me. Within the Internet protocol context I have alway
s
seen significant concern for reducing the number of exchanges, because
additional exchanges (hand-shakes) can -- and often do -- have painful
round-trip latencies. (Server capacity can be a concern, of course, but not f
or
this issue.)
For all of the massive improvements in the Internet's infrastructure, my
impression is that round-trip delays can still be problematic.
To this end, the high chatter rate of http seems less a basis for encouraging
other protocols to chatter more, than a case of remarkable good luck... unles
s
you happen to be on a path that has high latencies frequently, or experience t
oo
many of these extra handshakes.
Is it true that we no longer need to worry about regularly adding extra
round-trips to popular protocols that operate over the open Internet?
A lot depends on the expected operational environment. All the massive
improvements in Internet infrastructure haven't done much for the speed
of light.
For protocols whose *usual* -- not exclusive -- operational environment
is on a LAN or within an campus, round trips don't matter that much.
For things that might be cross-US or intercontinental, things *can't*
get too much better.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf