On Mon, Jul 22, 2013 at 1:27 PM, Trevor Perrin <[email protected]> wrote:
> On Mon, Jul 22, 2013 at 10:20 AM, Joseph Bonneau <[email protected]> > wrote: > > > >> It would prevent that because the transmitted cookie from the > >> legitimate browser is bound to that browser's TLS connection, via a > >> MAC. So the MITM can't reuse the cookie. > > > What prevents this, which seems like an attack the system is designed to > > guard against? > > The "cookie_key", which is derived from the original TLS connection > where the server sent the cookie. > > This key is never transmitted, so it won't be known to a MITM attacker. Thanks, this makes more sense now. This seems to means the server either needs to store (and verify) the correct cookie_key for every connection it has ever sent a cookie on, or use the "stateless" variant you mentioned. I think simplifying the proposal and only having the "stateless" variant makes more sense-really this is just assuming the server has a long-lived cookie-minting secret, which is also assumed in ChannelID and other proposals. The difference here is that instead of binding to an Origin-bound certificate to lock to a particular client, you're binding to the original TLS master secret on which the cookie was set. Makes sense to me now but I think this could be spelled out much more clearly. > > > Trevor >
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
