Goal/Non-Goal definition has multiple interpretations.

[alextok]

I interpret Non-Goal as "If OS supports the device binding, it should be secure, otherwise - no'. However, it is not clear for me, and I believe should be explicitly called out, if the following attack is goal to cover or not. Assume a device supports the hardware binding, but it doesn't stop a malware to generate an exportable key and use it for the binding of cookies, then export key with cookie on a controlled device, and forever use it from there. Is it goal to cover this attack or non-goal?

[kmonsen]

How and where keys are stored are to some degree left to the user agent. Ideally keys should be stored in a way that an attacker with total control over the users device will not be able to export the key. On Windows there are two different type of keys that enable this.

From my understanding of your attack, yes the goal is to stop it. Keys should normally not be exportable. It should not be possible to sign messages with this key from a different device, but malware running on the users device will still be able to sign as the keys are not app isolated.

There is another corner case were the attack is not prevented. If the attacker has malware running inside Chrome, or between Chrome and the key storage, at the time of a new session registration it is possible the attacker can force a not safe key.

Thank you for the comment, I will update this section a bit more.

[alextok]

I think the point is, the attacker can bring its own keys, stored in the attacker storage, and given it is system level malware, it can simulate or ask Chrome to perform whole handshake with them.

It is not about stealing a key that already generated, it is about bring its own keys.

Even if Chrome uses the most secure storage, what stops the attacker to bring its own key?

[arnar]

Thanks, this is indeed worth clarifying. The goal of the proposal is to make it feasible for browsers and operating systems to provide device binding. Two non-goals are:

1. (to your question) It is not a goal of this proposal to provide any kind of primitives to ensure, or otherwise prove to websites, that the initial credential create at session bootstrap is device bound. For now this is left as an implementation dependent aspect. The reason is that such assurances are nuanced, have to do with general system health during sign-in, and generally a larger set of concerns than we want the protocol here to provide.

2. It is not a goal to specify requirements on implementors in terms of what is "sufficient device binding", because that question is very platform dependent. This proposal provides a protocol that aims to be adoptable by websites, which then enables browser and platform vendors to provide strong bindings (currently impossible with cookies alone).

[simon-friedberger]

Thanks, this is indeed worth clarifying. The goal of the proposal is to make it feasible for browsers and operating systems to provide device binding. Two non-goals are:

1. (to your question) It is not a goal of this proposal to provide any kind of primitives to ensure, or otherwise prove to websites, that the initial credential create at session bootstrap is device bound. For now this is left as an implementation dependent aspect. The reason is that such assurances are nuanced, have to do with general system health during sign-in, and generally a larger set of concerns than we want the protocol here to provide.

2. It is not a goal to specify requirements on implementors in terms of what is "sufficient device binding", because that question is very platform dependent. This proposal provides a protocol that aims to be adoptable by websites, which then enables browser and platform vendors to provide strong bindings (currently impossible with cookies alone).

It would be good to point this out in the section on TPM consideration. It begs the question what happens when a TPM is not available.