Add to sec cons a brief discussion of the sec properties accrued by authnr & client platform proximity

[emlun]

How about something like this?

Fixes #1257.

---

Preview | Diff

[equalsJeffH]

Overall this seems really good. I was wondering if we need to go into this detail with something aimed at protocol designers, but then we have an extant case (cases?) of folks building on top of webauthn and running directly into these issues. So perhaps we ought to include this, tho a consideration is how much detail to get into. e.g., fig 8 is discussing attacks at authn time, but there's also, say, MITM attacks at "binding" time when the authnr is introduced to the authnr service server. Etc.

[equalsJeffH]

LGTM, thx @emlun!

[emlun]

Rebased onto master.

[nadalin]

@akshayku Please review so we can merge this or move it to next WD

[equalsJeffH]

AFAIK @agl doesn't have time in the next 30 min to review this, and it was my thought to have him do so, thus I've removed him from reviewer list, and suggest we land this -- can always revise if necessary in the run-up to WD-03, CR, etc.

[nadalin]

@agl @leshi @akshayku Please review

[agl]

I think something like this is valuable but I'm not sure that the current working is quite capturing what I see as the essence. (Or, perhaps nobody else views the essence in the same way, in which case LGTM.)

As currently written, this text emphasises that client and RP enforcement of the RP ID is critical to security. Absolutely agree with this part. Then, in my mind the critical point is that the authenticator (which is the trusted device here, assuming that the phisher controls their own client machine) gets assurances by transmitting over a medium that has limited range. (Direct USB connections have the most limited range, but BLE is still local.)

This ensures that an attacker must have a subverted a device physically close to the authenticator, which is a much higher bar than if the authenticator is willing to communicate across the internet.

[nickmooney]

I think @agl's concerns are partially addressed by the section that discusses what tradeoffs may be made if the client and the authenticator are not being discussed directly. I still see compelling use cases for authentications where a "proximal" transport isn't possible (and I would argue that proximity is a bandaid, not a guarantee).

It would be reasonable to add some discussion more directly of what the benefits of proximity are; ultimately I think it's a choice that is best left up to implementors equipped with an understanding of the security tradeoffs involved rather than being mandated in any way.

[emlun]

Thanks @agl, that's a very good point and I agree. I've rewritten the section (now much shorter!) with equal focus on both the physical proximity aspect and the direct communication aspect.

[agl]

(Your call on whether to add the commas. I know that opinions vary on these things and am fine either way.)

[equalsJeffH]

LGTM, thx @emlun :)

[equalsJeffH]

on 2020-02-19 call: akshay reports msft looking into using remote SKs to remote desktop and in the desktop do things via webauthn. AGL reports that this use case is supported in chrome remote desktop. threat model remains that an attacker must compromise something nearby the user. Ought to add something to client data when operating in such a scenario. Ie. this PRs language does not preclude remote desktop use cases.