Given the range of Martin's comments, I'd be surprised if that could be reduced to a PR;-)
But let me ask a question meanwhile - how often does HRR actually happen and could we not just let ECH fail in a bunch of situations that would otherwise require all this new complexity? Thanks, S. On 01/04/2021 18:29, Christopher Patton wrote:
Hi Martin, would you mind working out a PR? I think being able to compare 407 to a concrete alternative would be helpful. Just so that we're on the same page, here's a quick summary of the issues that 407 is designed to solve. (These may or may not be problems in your view, and I don't claim this list is exhaustive.) - 233: No acceptance signal until after HRR, so the procedure for computing CH2 is underspecified. This can be avoided by advertising the same preferences in CHI/CHO, but the spec doesn't require this. - 373: To fix 3233, can we put an acceptance signal in HRR.random? Probably not, since HRR.random has a value specified in RFC8446. - 358: RFC8446 allows the value of an extension in CH2 to differ from CH1 only if the extension appears in HRR. - 333: "Split mode" is broken, since the client doesn't know who the cookie is for. Best, Chris P. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
