- From: Nico Williams <nico@cryptonector.com>
- Date: Tue, 7 Jun 2011 17:35:31 -0500
- To: "Paul E. Jones" <paulej@packetizer.com>
- Cc: Eran Hammer-Lahav <eran@hueniverse.com>, apps-discuss@ietf.org, Ben Adida <ben@adida.net>, Adam Barth <adam@adambarth.com>, http-state@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, OAuth WG <oauth@ietf.org>
On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones <paulej@packetizer.com> wrote: > I fully agree with you that using TLS is usually preferred. That said, we encounter situations where there were a large number of client/server interactions and the data conveyed is not confidential information in any way. Using TLS can significantly decreases server performance, particularly when there are a number of separate connections that are established and broken. > > So, we were trying to find a non-TLS solution that still provides a way to ensure the server can identify the user and that both can verify that data has not been tampered in flight. (It would still be preferred to establish security relations with TLS, though we were open to other solutions.) I don't see the point of having a MAC instead of a cookie for HTTP requests sent without TLS, not unless you cover enough of the request (and response). Of course, you'll want two different cookies -- one for HTTP and one for HTTPS. I think you've just convinced me that this MAC adds no value whatsoever. Nico --
Received on Tuesday, 7 June 2011 22:35:54 UTC