On Thu, Oct 13, 2022 at 8:58 AM Marwan Fayed <marwan= 40cloudflare....@dmarc.ietf.org> wrote: ...
> There are really only two ways to populate the outer-SNI. One way is a > fixed name that easily identifies the content operator, e.g. > ‘operator-ech.com’. In that case, the number of packets with the fixed > outer SNI is sufficiently extraordinary as to either or both: > (a) visibly identify the operator, in which case the trade-off for > client privacy is operator exposure; and This is incorrect: the operator is already identified unambiguously by the destination IP address, so nothing new is "exposed". (b) make it trivially easy for ECH to be blocked, thereby severing > many clients from the operator, and the Internet entirely if all > operators deploy. Per the above, I do not believe ECH has any effect on this. The hypothetical "blocker" here can easily block all access to a given operator whether or not ECH is in use. This is an ‘anti-goal’. > > Alternatively, the operator generates a random outer-SNI for each DNS > query This would not have any effect on the ability of the hypothetical "blocker" to block all access to any operator that it knows is using ECH, so there's no reason to do this. It would also break the ECH mismatch fallback mechanism, which requires that the operator hold a valid certificate for the outer SNI. ... > There is much more that can be said but -- again, first and foremost > -- it would be great to figure out if there is interest in the wg I don't think this would be a good use of working group time: 1. There is no use speculating about the motivation of parties who aren't participating in the working group. 2. The concerns seem to be based on a misunderstanding of what information is concealed by ECH. 3. The group is explicitly chartered to standardize ECH, so that is not open for debate (except in a rechartering context). I do think we have a lot to learn about the operational challenges of deploying ECH, but our discussion about that should be driven by technical reports from deployments, not speculation about political problems.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
