Dave Cridland <dave(_at_)cridland(_dot_)net> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf