Tighten security scope by port

[annevk]

@jeisinger has been looking at restricting cookies/document.domain further. Since those are relatively old features, I was wondering if we could start perhaps by tightening new features build upon the same concepts.

The idea is that instead of the scope being scheme and registrable domain, it's scheme, registrable domain, and port if the port is the default port for the scheme. So effectively add a bit to the comparison. (The scheme part isn't needed for Webauthn as it's secure context only and is ignored for cookies, for what it's worth.)

However, given how https://w3c.github.io/webauthn/#rp-id is defined it seems port isn't even stored so this may not be possible to do?

cc @mikewest

[equalsJeffH]

... and port if the port is the default port for the scheme.

do you mean to say "... and port if the port is not the default port for the scheme." ?

[annevk]

The idea @jeisinger had for cookies/document.domain is that if the port is 443 and scheme https (or 80 and http, but that's not applicable here), you only allow that port. If it's any other port, it can go cross-port.

[equalsJeffH]

@annevk you are referring to issue whatwg/html#2792 ?

[annevk]

Yes! Thanks for finding that.

[emlun]

What is the reason to allow viewing example.com and www.example.com as the same domain, but not example.com and example.com:1234? The former two might not even resolve to the same address in DNS, but the latter two always will, right?

[annevk]

We don't want to allow example.com <> www.example.com either, but it's there for some things due to cookies primarily. Unfortunately WebAuthn adopted that model, due to having to be compatible with cookies. The question is then if we can add some restrictions back to make the attack space less open-ended.

[nadalin]

@equalsJeffH Any chance to triage this yet ?

[equalsJeffH]

@annevk wrote in #873 (comment)

If it's any other port, it can go cross-port.

Could you please explain further, I dont understand this part. thx.

[annevk]

Port 443 matches 443, non-443 matches non-443.

[nadalin]

@annevk Does not seem to be anything we can do this release/level moving to next level

[equalsJeffH]

pivoting back here, sorry for the lag...

Ok, so I think I understand now what @annevk is asking for, if this clarification is correct: by this..

Port 443 matches 443, non-443 matches non-443.

.. @annevk actually means:

Port 443 matches only port 443, any non-443 matches any non-443, when doing RP ID matching, assuming RP IDs are re-defined to be a {host, port} pair.

Essentially, IIUC, it is to add a port restriction to the RP ID matching algorithm, which is summarized in the RP ID's definition's Note:, to be:

Note: An RP ID is based on a host's domain name, and port (only when the port is 443). It does not itself include a scheme, as an origin does. The RP ID of a public key credential determines its scope. I.e., it determines the set of origins on which the public key credential may be exercised, as follows:

• The RP ID must be equal to the origin's effective domain, or a registrable domain suffix of the origin's effective domain.

• The origin's scheme must be https.

• The origin's port must be 443 if the RP ID's port is 443. Otherwise, any non-443 port matches any other non-443 port.

For example, given a Relying Party whose origin is https://login.example.com:1337, then the following RP IDs are valid: {login.example.com, !443} (default) and {example.com, !443}, but not {m.login.example.com, 443} and not {com, 443}, nor {com, !443}.

In the above I've invented a notation to denote an RP ID as a {effective domain, port} pair, which is what we would need to change RP ID to be in order to effect what @annevk is asking.

@annevk in orig post:

However, given how https://w3c.github.io/webauthn/#rp-id is defined it seems port isn't even stored so this may not be possible to do?

yeah, it'd be a pretty big breaking change at this point for the spec and for implementations. I agree with moving this to Level 2 milestone.

[emlun]

Do we want to include port as one of the parameters set by the RP? Another solution could be that the RP always specifies the rpId without port, and the client adds the port before sending the (host, port) tuple down to the authenticator which matches that against the stored credentials.

It would also be preferable if we could do this in a backwards compatible way. I think one way to do this is if the client would append a : character to options.rp.id for non-443 origins (because an RP ID cannot contain the : character, right?). That should be backwards compatible with both existing authenticators and existing credentials (the latter of which would then only be usable on :443 origins) - github.com and github.com: are just two unrelated RP IDs for all the authenticator cares, and credentials for the former continue to work as before.

[annevk]

That would work, however, if this isn't feasible for v1 and given all implementations have shipped already, it's not immediately clear to me if this is still worth pursuing.

In whatwg/fetch#687 (comment) not everyone was convinced that such a port restriction would be meaningful either, so maybe we should just give up on that altogether?

[equalsJeffH]

Yeah, given the discussion in whatwg/fetch#687, and also whatwg/html#2792 (comment), I'm thinking closing this is appropriate, espcially if whatwg/html#2792 is closed.

[emlun]

I'm not convinced this would add much security in practice, but I suppose a little extra defense in depth won't hurt (other than costing a slight increase in complexity). I would support doing this, but I'm not against closing it.

[annevk]

I closed the HTML issue. Closing this as well.