Dave Cridland <dave@xxxxxxxxxxxx> writes: > On Sun Feb 19 23:23:59 2006, Dave Crocker wrote: >> 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 always 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 for this issue.) >> > Well, for those of us looking at Lemonade, etc, I think we're still > very concerned about every round-trip. Server capacity, too, is a very > real problem, and, while I admit to not having looked at this > specification yet, given what I've read thus far, I'm assuming this > has some applicability to email protocols as well as HTTP, which would > affect Lemonade. Well, I'm not claiming that latency isn't a factor in protocol performance. What I'm claiming is that it's not clear that latency in the initial connection setup handshake (in this case the TLS one) is a major factor in protocol performance. Recall that the way that TLS works is that you do an initial handshake to establish the keys and then you send data of the negotiated channel. What we're discussing is whether it's OK for this to take a few extra round-trips at the setup of the first connection (and not necessarily afterwards because of TLS session caching). So, we're not talking about adding messages to every activity of the higher level protocol. So, what I'm arguing is that except for applications where initial connection setup is a large fraction of the cost of the entire connection, I think it's not worth optimizing the initial connection setup very much. And until you've profiled the protocols in question it's hard to know which case you're in. >> 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? > > No. > > As far as I'm aware, there is no protocol in existence which somebody, > somewhere, does not actively use over a mobile phone link, or a slow > analogue modem, and this is especially true of TLS enabled protocols > such as HTTP, email protocols, etc. Well, I hear what you're saying, but when I check my mail over my cell phone, it's pretty clear that the time isn't going to TLS connection setup. -Ekr _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf