At 12:19 PM -0500 11/2/09, Rob Austein wrote:
At Mon, 2 Nov 2009 11:07:40 -0500, Steve Kent wrote:
I am not sure what motivates Rob to say that he is not convinced
about the extent of the session security offered by HTTPS. (Is it
related to the session resumption feature in TLS?)
Nope. It's related to HTTP not really having any such thing as a
session to protect. It is of course possible that we all (or perhaps
just I) misunderstood your advice, in which case please expound.
In the TLS context I think of a session as the set of traffic sent
after the TLS handshake completes and before a new handshake occurs,
between the same pair of IP addresses. Yes, there is no explicit end
of session message in TLS, which makes it hard to define the end of a
session. However, if a server times out an inactive session, the
client will need to perform a handshake to re-establish it, so there
is an opportunity for the server to unilaterally end a session at any
time. Since the goal of using TLS here is to help protect servers,
this seems like a reasonable strategy. (And as I noted above, a
session resumption request by a client can always be rejected by a
server.) Any received traffic that is not protected under the keys
established at the start of the session will be rejected. I assume
that a new handshake should cause the old keys to be replaced. So the
server is well-positioned to decide when a session has ended.
Is your point is that the handshake imposes a crypto processing
burden on the server, and that this reduces the DoS benefits? Note
that there there are a number of hardware options available to
off-load the processing associated with the handshake.
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
