On Tue, Aug 20, 2013 at 1:39 AM, Yoav Nir <[email protected]> wrote:
> Hi Trevor.
>
> I think (a) is definitely worth doing, but I also think that (b) can be done
> along the way.
Interesting... If we were to prioritize them, I'd argue the reverse:
(b) ("Origin Cookies") strikes me as the most economical, since it
fully addresses cookie-forcing and stealing provided TLS is secure.
> Is there some reason why (a) and (b) can't be requirements filled by a single
> mechanism?
That's exactly what Smart Cookies attempt - they have origin-binding,
*and* cryptographic-binding via MAC.
But I don't know whether that's the best approach. It might be easier
to push things like ChannelID and Origin Cookies separately.
> Regarding smart cookies vs channel ID: Not changing TLS is a definite
> advantage of Smart Cookies. Reading that message again ([1]), I'm not sure
> whether the cookie_binding is necessary,
It's necessary so the transmitted MAC doesn't become a "bearer token"
that could be re-used by anyone.
> but I get that it protects against passing cookies. The only issue I have
> with this
> is that it relies on extractors, and so will break at TLS proxies. While this
> is good
> from a security perspective, it's a killer for deployment. I think that
> Channel ID
> works in the presence of proxies, assuming the proxies are updated and move
> the encrypted extension unchanged.
I assumed that both Smart Cookies and ChannelID would break at TLS
proxies until those proxies are updated to pass some information
downstream. And then would work.
Since Smart Cookies don't affect the bytes-on-the-wire, whereas
ChannelID modifies the Handshake protocol, I was also assuming Smart
Cookies would be the easier change.
Is that wrong?
Trevor
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
