Re: [http-state] draft-salgueiro-secure-state-management-04.txt

[Adam Barth <[e-mail]>]

Overall feedback:

There are large performance problems with this proposal.  However, I
like the general idea of the user agent and the server establishing
key material that's used to authenticate various parts of the HTTP
request.

Some random detailed comments:

===
   In every request from the user agent to the server, the user agent
   MUST advertise its support for the Secure State Management
   procedures defined in this document.
===

User agent's aren't going to like this requirement because it bloats
UA => Server request for everyone.

===
      SSM-Functions = "SSM-Functions" ":" MAC-Function
                      *["," *SP MAC-Function]
===

Presumably LWS instead of SP.

===
   A client MUST NOT issue
   concurrent requests that utilize the same security association
   handle and session handle, as the server will not be able to
   differentiate between legitimate requests and requests that are, in
   fact, replay attacks.
===

This is terrible for performance.  It's extremely common to have
multiple requests in flight to a server and will only become more
common in the future.

===
   Once an association has been established, it MAY be used
   subsequently over either HTTP or HTTPS when the client issues
   requests to the server.
===

What about other protocols?  Can I use it with gopher?  What about
SPDY?  What about Future-Protocol-That's-Awesome?

===
   When using HTTPS and establishing a new security association, the
   server MUST reply to requests that contain the SSM-Functions header
   and that do not demonstrate having a valid security association with
   a 401 Unauthorized as shown below:
===

This is slow because it introduces an extra round-trip between the UA
and the server to establish the security association.  For servers
that care about latency, that's a huge hit in many common deployment
scenarios, especially mobile.

===
      GET / HTTP/1.1
      SSM-Functions: hmac-md5, hmac-sha-1
      SSM-Parameters: assoc=12345; session=1; nonce=1;
                components=Request-Line;
                mac=2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
===

That's a lot of junk to send with each request.  People believe that
Cookie headers area already too long!

===
      HTTP/1.1 401 Unauthorized
      WWW-Authenticate: SSM transport=https, port=443
===

Why not just use a regular HTTP redirect?

I don't understand how the user agent chooses which components to use.
 Does the server request these?  Is the user agent just supposed to be
prescient?

Adam


On Mon, Feb 21, 2011 at 11:09 AM, Gonzalo Salgueiro <[e-mail]> wrote:
> Folks,
> We just published a significantly revised version of the secure state
> management draft that we had been working on.  The new draft can be found
> here:
> http://tools.ietf.org/html/draft-salgueiro-secure-state-management-04
>
> We had received mixed feedback before, but it seemed there were two
> recurring themes:
> ·         We wanted to move away from cookies for secure state management,
> though perhaps continuing to use cookies as a means of identifying the
> remote user agent
> ·         We need to have a solution that works over HTTP that does not
> require the use of Diffie-Hellman
>
> We took a step back to look at the problem we were trying to solve.  What we
> want is to ensure that a request coming from a client could be trusted, even
> if transmitted over HTTP.  So, what we wanted really wasn’t a secure cookie,
> but a guarantee that the request is genuine.
>
> With this draft, we’ve moved away from cookies and focus on only providing
> message authentication.  To provide message authentication, we still
> establish an association between the client and server.  We still allow for
> Diffie-Hellman to be used, but we have a mechanism in place to allow HTTPS
> to be used for the sole purpose of establishing associations, too.  The end
> result is that, with this draft, we can provide message integrity and we can
> avoid replay of messages.
>
> We invite you to look at this revised draft and provide us with feedback.
> Warm Regards,
> Gonzalo
> _______________________________________________
> http-state mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-state
>
>