One more config rotation bit.

[martinduke]

Fixes #12.

Also addresses another version assumption and deletes a reference to the in-band protocol.

[huitema]

Shouldn't the CID length be implicit, or maybe part of the configuration?

[martinduke]

It often is, but we specifically added an optional self-encoded length to assist with hardware crypto offload.

[martinthomson]

Of course you could get even more space here if you were willing to impose constraints on length. You don't lose that many options if you do that either. You just have to choose which options don't get to play. I recommend everything from 0 (which you can't not have) to 4. But that's just me, I'm sure.

My original thought here was that the configuration could indicate how many bits were spent on this vs. server ID. Then you don't have any problems that might arise from constrained space. Nor do you need to have a server ID length either.

But of course that moves the complexity into implementations. For that, it's not much, and I would say that implementations are free to limit the range of values they support (probably more so for the load balancer than the more-flexible server). And there is nothing wrong with making a suggestion either.

[martinthomson]

Suggested change

	these three bits allow three mutually exclusive server pools to coexist, and for
	these three bits allow four mutually exclusive server pools to coexist, and for

That assumes of course that you need two keys per server pool, as opposed to rotating each pool one by one, in which case you can have seven (assuming excellent, though probably unrealistically difficult, coordination).

I don't think that you need to be so definitive about this. Say that you might use this to create 4 distinct pools that are able to independently use two distinct configurations (and therefore keys), or other arrangements.

[martinduke]

Since '111' is reserved for 5-tuple routing, there are 7 codepoints. I believe 3 is the correct number. But I should say "at least" three.

[martinduke]

@martinthomson

My original thought here was that the configuration could indicate how many bits were spent on this vs. server ID.

I don't think this will work in practice. The self-encoded length bit is mostly there for crypto offload devices on the server. So it's entirely possible (likely, even) that the LB doesn't care about the self-encoded length, but the server absolutely needs to use the 5 bits in that way.

I see other problems, but this is the most important one.

[huitema]

You are placing server specific bits in the CID: an identifier of the class of servers served by a load-balancer, but I am worried about privacy issues. If I understand the intent, you want to partition the set of servers behind the load-balancer based on some level of trust. But doing that creates a privacy issue. When using ESNI/ECH, the privacy of client and services relies on hiding within the "anonymity set" of all services behind the load balancer. Having multiple classes partitions that set. (Allowing multiple CID lengths has the same effect.)

[martinduke]

Good point, @huitema. Would you prefer we stick with two bits and have some other way of solving the issue of mutually mistrustful servers, or would you be satisfied if we just added this privacy concern to the security considerations?

[huitema]

We need privacy considerations in any case. If you are concerned about privacy, you probably should not use the clear text and obfuscated method, and you also want to make sure that all servers in the anonymity set use the same CID length. (If you are serious about privacy or security, you should probably never use the clear text or obfuscated methods anyhow; maybe they should not make it to the final draft; but that's a different issue.)

On the specific case of the third bit, the effect on privacy is not good. You could say that "if you are serious about privacy, all servers in the same anonymity set must use the same 3 bits pattern". Or the same 2 bits pattern, for that matter. I do think sticking with 2 bits would be better, but I am not sure that I understand the use case for three bits. Is there that much of a security difference between "the CID key is shared by 2000 servers" and "the CID key is shared by only 1000 servers"? Are you not just hitting the practical deployment consideration that widely shared secrets are not going to stay secret for long?

[martinduke]

Are you not just hitting the practical deployment consideration that widely shared secrets are not going to stay secret for long?

That's not the concern. The issue is that some of the servers behind the LB might not be trustworthy in terms of being able to link your clients. (e.g. a hosting service with multiple customers.)

[huitema]

That's not the concern. The issue is that some of the servers behind the LB might not be trustworthy in terms of being able to link your clients. (e.g. a hosting service with multiple customers.)

Care to explain a bit more? You are maybe pointing here at deployment considerations. There seems to be several deployment cases:

1. The "example.com" company manages its own pool of servers,

2. The content delivery company "example.net" manages a bunch of edge servers that serve content for a variety of customers

3. The hosting company "example.example" provides virtual machines to a bunch of customers with additional services like load balancing, firewall or DDoS protection.

In all these cases, there are different trust levels. It seems that the draft is making hidden assumptions about these levels. You may want to add something like "deployment considerations".

[martinduke]

Closed #12 with no action, so closing this too.