In message <43F8FE0F.3060309@xxxxxxxxxxxx>, 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf