Public name rewriting

[martinthomson]

Is there any sense in having the server validate the value of the server name indication extension in the outer ClientHello? It seems like it might help avoid a trivial attack on DNS that might otherwise pass without notice or alarm. That is, an attack that copies the DNS QNAME in the public_name field.

There are various ways in which this might fail, but none of the scenarios that I can think of result in anything that a client or server might recognize as being alarming.

It is easy to detect and prevent this sort of interference: the client-facing server checks that the SNI matches the value it expects from the ECHConfig that has been selected. If the config might have changed, such that multiple values are valid, then the server can allow for that, but generally there will be just one valid value.

[sftcd]

Hiya,

On 23/02/2021 06:08, Martin Thomson wrote: Is there any sense in having the server validate the value of the server name indication extension in the outer ClientHello?

I think that check ought, at best, be a MAY, and not a MUST. The reason being to support non-browser clients, and as a possible additional hedge for circumvention tools (that may also be non-browser clients). I also suspect, but don't know, that omitting such checks might improve some hosting scenarios that could otherwise be a pain - where the hoster's lookup of any sni value is an expensive DB access to load the right key pair and cert. (Sure, that could be optimised but then we'd be adding yet more complexity to ECH deployment, which is worse than even all the complexity we've added to implementation;-) For example, when we've done work on curl, we allow an optional name on the command line that then overrides the ECHConfig.public_name. I don't see any reason to prevent that TBH. And I reckon it could enable some possibly interesting use-cases there's no reason for us to prevent.

It seems like it might help avoid a trivial attack on DNS that might otherwise pass without notice or alarm. That is, an attack that copies the DNS QNAME in the public_name field.

I'd have no problem if we said "if outerCH.sni==innerCH.sni" then ignore the innerCH, or something similar. But it ought be valid, and maybe even encouraged, to ignore the sni from the outerCH, when the innerCH works.

There are various ways in which this might fail, but none of the scenarios that I can think of result in anything that a client or server might recognize as being alarming. It is easy to detect and prevent this sort of interference: the client-facing server checks that the SNI matches the value it expects from the ECHConfig that has been selected. If the config might have changed, such that multiple values are valid, then the server can allow for that, but generally there will be just one valid value.

Again, I don't see sufficient benefit, so would rather keep the flexibility and easier deployment of omitting that. Cheers, S.

[davidben]

The entire ECHConfig is also bound into the decryption, so if the DNS is messing with ECHConfigs, you won't end up negotiating ECH. Copying the QNAME into the public name probably will successfully bounce ECH off via the recovery flow, but the DNS could just as easily have dropped the ECHConfig itself.

[chris-wood]

@martinthomson can you elaborate on the attack you had in mind? @davidben notes that the entire ECHConfig is now authenticated, so any disagreement between client and server will cause ECH negotiation failure.

[martinthomson]

I should have responded earlier (thought I did...). The fact that the configuration is covered prevents this from being a problem. I missed that.