Discuss acceptable use cases for site usage of CNAMEs

[samuelgoto]

In the FedID CG, we have, as a group, identified that it may be possible to preserve (in the absence of third party cookies) some of the deployment of identity federation through the use of CNAMEs and SameSite cookies.

We would like to know if what we have in mind is: (a) recommended by the browser community as a viable option long term - e.g. no mitigation / intervention planned - and if not (b) recommendations on where to go from here.

The pattern

1. A company, say rp.com, hires the services of another company, say idp.com, to host and manage its authentication system, typically giving them a rp.idp.com subdomain. @hlflanagan did I get this right?
2. When users navigate to rp.com they get redirected to rp.idp.com
3. rp.idp.com, hosted and controlled by idp.com, handles the user's authentication to rp.idp.com and sets rp.idp.com first party cookies
4. rp.idp.com navigates the user back to rp.com with the user's identity in the URL parameters.
5. rp.com takes the user's identity from the URL parameters and logs the user in
6. rp.com embeds iframes pointing to rp.idp.com to continue managing the user's sessions (e.g. logging out)

The Problem

• Step (4) embeds a user identifier in URL parameters
• Step (6) depends on third party cookies

The Proposal

What's being suggested, and what we are looking for guidance is:

1. As part of step (1), the RP can change its DNS configuration to point login.rp.com to an agreed upon IDP IP address, to be used in replacement of rp.idp.com.
2. Step (5) and (7) are no longer a problem because rp.com and login.rp.com are SameSite.

This has desire property of being fairly compatible with the current deployment, requiring a few configuration
changes (rather than using new APIs).

It doesn't seem like that would introduce any new surface that would be able to be abused for cross-site tracking, because it would seem that, even if the traffic is served by the IDP, the cookies would be partitioned by SameSite/RPs.

1. Say tracker.com asks websites to add CNAMES pointing to it.
2. tracker.a.com points to the tracker.com's IP address
3. tracker.b.com points to the tracker.com's IP address too
4. When tracker.com gets the two requests, the cookies are partitioned by site, so it can't
   join traffic between the two requests

Alternatives considered

There a few alternatives that were considered here, along the lines of First Party Sets, Storage Access API and FedCM.

It is unclear to us if there are security (e.g. DNS not being secured, are there network attacking vectors?) and privacy considerations (e.g. can this be abused? and if so, can we distinguish abuse from federation?) we are underestimating, so looking for overall directional guidance.

We would like to know:

1. Can / should the FedID CG use CNAMES as a recommendation, or would we run into a wall long term?
2. And if so, where should we go from here?

I'm specifically interested in learning more broadly from browser vendors, but specifically from WebKit on CNAME cloaking and bounce tracking:

https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/

[TanviHacks]

Thanks Sam for filing this issue! Do you want to discuss this during Thursday's teleconference?

[samuelgoto]

Yeah, that would be great. @erik-anderson can you help us with that?

[hlflanagan]

"A company, say rp.com, hires the services of another company, say idp.com, to host and manage its authentication system, typically giving them a rp.idp.com subdomain." is a common pattern, yes. As I understand it, CNAMEs are complicated to maintain; doable, but less common.

[gffletch]

One concern I have is that requiring CNAMEs to solve this problem seems overly prescriptive. There are additional complications that come with using the CNAME solution that many RPs do not see as being necessary (e.g. certificate management).

[samuelgoto]

One concern I have is that requiring CNAMEs to solve this problem seems overly prescriptive. There are additional complications that come with using the CNAME solution that many RPs do not see as being necessary (e.g. certificate management).

I'd like to focus/narrow this issue/discussion on whether CNAMES is a viable option (as far as browsers are concerned) before assessing whether that's a good idea (as far as IDPs are concerned). If the result to viable comes back as negative, it doesn't matter whether this is a good idea or not. If it is viable, its merits can be compared against other alternatives, rather than in isolation.

[krgovind]

Based on the discussion on the last call, I think it was made clear that CNAMEs are not a viable solution. Specifically Safari, and Samsung browsers are already placing restrictions; so we need to find alternative solutions for this use-case.

A somewhat naive question that I have for the identity folks (perhaps @hlflanagan @gffletch or @samuelgoto can help with this) is - as a long-term solution, would you consider having rp.com embed an iframe to rp.idp.com and perform the login flow within the iframe? Are there security/other considerations that make this undesirable?

[lolaodelola]

@samuelgoto This is definitely not a viable option from a Samsung Internet perspective. @krgovind if the rp.idp.com iframe is embedded in rp.com wouldn't the original issue still stand? i.e. rp.idp.com will still need to use 3rd party cookies to manage user sessions after login on rp.com since they're not SameSite. Or have I missed something here?

[krgovind]

@krgovind if the rp.idp.com iframe is embedded in rp.com wouldn't the original issue still stand? i.e. rp.idp.com will still need to use 3rd party cookies to manage user sessions after login on rp.com since they're not SameSite. Or have I missed something here?

@lolaodelola - Indeed. We would recommend the iframe use partitioned cross-site cookies. For example, Chrome is experimenting with a new Partitioned attribute (blog post). Partitioned state prevents cross-site tracking via state-based mechanisms.

[samuelgoto]

would you consider having rp.com embed an iframe to rp.idp.com and perform the login flow within the iframe?

Ah, interesting question. I do believe that, in the case when the rp.idp.com is providing a service to rp.com, that rp.idp.com would be possible to be embedded into rp.com and take authentication credentials in it (e.g. usernames/passwords).

I don't think this is common, so there is probably something I'm missing here, but I can ask around to check what I'm getting wrong.