# TLS Virtual Interim 3 ## April 1, 2021 - 1900-2000 UTC Notes by Christopher Patton ## Agenda ECH Issues - https://github.com/tlswg/draft-ietf-tls-esni/issues ## Reused HPKE context: https://github.com/tlswg/draft-ietf-tls-esni/issues/397 * Current spec doesn't allow use of the "single-shot API" of HPKE. * sftcd: maybe defer this until we've settled the HRR issue * UNRESOLVED: Resolve after 407 ## Compression: https://github.com/tlswg/draft-ietf-tls-esni/issues/398 * stfcd: "ech_outer_extensions" adds implementation complexity. Is it necessary to be this general necessary? * Ben Schwartz: Worth "re-spelling" the mechanism? Maybe the inner is the same unless an extension is present, maybe add a means to remove from the inner. * CPatton: not too difficult for the server; optional for the client * CWood: has been implemented and is interoperable * MT: NSS implementation had some bugs, but it was simple programming; could go either way * stfcd: I'm in the minority, so it's ok for the chairs to override me. * RESOLUTION: Close this issue. (If someone comes up with something simpler, then it seems like people are open to that. File a PR!) ## Acceptance signal: https://github.com/tlswg/draft-ietf-tls-esni/issues/399 * Acceptance signal adds complexity: client may need to re-process SH. This causes implementation complexity. * Relaxation: Just use CHInner.random as the secret to derive the signal. Hash over the entire SH (in particular the server's key shares). * CWood: Active "don't stick out" attacks suggest we don't understand whether this relaxation is safe. Proposal: punt until we have security analysis. * MT: Not a problem if cipher suite preferences are the same in CHInner / CHOuter. * David B.: Weird interaction with PSK. PSK is inserted in the key schedule before the decision is made. Have to back up and change this on retry. * MT: PSK/ECH interaction is not fully understood. * UNRESOLVED: Resolve after 407 and we have an analysis to support the final design. ## Validating ECHConfig.public_name: https://github.com/tlswg/draft-ietf-tls-esni/pull/413 * Issue 405: Stuff from DNS can find its way into CHOuter. Do we restrict the public name to host names, or allow IP addresses? Should we exclude IPv4? * CWood: What goes in the public_name of ECHConfig? How to construct CHOuter using this information? (Ties into issue 396 (whether public_name MUST match CHOuter.server_name).) * Ben Schwartz: Spend one byte and have public_name be a server name, as in RFC6066. We may need more extensibility in the future, so let's add it now. * MT: Distinction between DNS names and IP address is what matters. Don't spend the byte. The only real issue is the ambiguity between DNS names and IPv4. Dan's suggestion is the right one: the name in the public_name is what you validate. * stfcd: public_name is *a* name you can use to validate the fallback cert. I agree. * CWood: Let's rewrite the text so that it talks about how to construct CHOuter using the identity that will be validated. * Ben Schwartz: I don't like the idea of trying to parse this string in different ways. If what we mean is "identity that is validated", then don't we need identities as defined in the X509 spec? * RESOLUTION: Take CWood's suggestion (rename as public_identity instead of public_name), GeneralName (5280)? ## MUST include outer name: https://github.com/tlswg/draft-ietf-tls-esni/issues/396 * RESOLUTION: Same resolution as 413. ## HRRInner/Outer: https://github.com/tlswg/draft-ietf-tls-esni/pull/407 * David B.: HRR is a disaster, but we're stuck with it. * Issues: * HRR in current draft applies to CHInner and CHOuter. We "patch" this in the spec by guiding clients towards keeping HRR-sensitive parameters the same in CHInner and CHOuter. * "Split mode". If backend server sends a cookie, the client doesn't know whether to send it to client-facing server or backend server. * "don't stick out" attacks apply to current design. * Current design contradicts RFC8446. * MT: * Happy to solve the "cookie" problem by having client-facing server and backend server do something out-of-band. * HRR forgery attack on "don't stick out" is acceptable * Complexity is unacceptable. * David B.: Matching HRR-sensitive parameters in CHInner / CHOuter is trickier than MT appears to think. * stfcd: Can we just accept that some edge cases are failures? * MT: The rule should be that the client has the same inner / outer preferences for any parameter that impacts the handshake secret. This should solve the main problem. * EKR: * Three types of complexity: implementation, spec, and analytical. CHInner / CHOuter was an attempt to solve analytical complexity. * Chris P.: HRRInner / HRROuter solves future composition issues with ECH. * Ben Schwartz: Reasonable to demand that key_shares is the same, it's much harder to demand that client-facing server and backend server have the same preferences. * David B.: PROPOSAL: Someone write down CHOuter / CHInner matching rules that gets rough consensus. * MT: * Cookie thing: It's a corner case. Let's ignore it. * The rules we have for CHI/CHO matching are correct, modulo contradiction with 8446. * stfcd: Give me the numbers! How common is HRR? * Chris P.: For Cloudflare it's rare, but not neglible. * David B.: Also rare for Chrome. But the more important point is that the server can't guarantee it doesn't need to send HRR. (We got HRR wrong!) * EKR: Is encrypting HRR complex? * MT: Because HRR is rare, we're talking about code that is not gonna get thoroughly tested. * EKR / David B.: Back and fourth on how we landed on the HRRInner / HRROuter. * David B.: Can we reduce the complexity of the current PR? * Ben Schwartz: Backend server can generate always generate a SH.random tag. (acceptance signal?) * UNRESOLVED: We will put together a design team to iron out HRR. The team will propose a solution in a month at the next TLS interim.