# TLS VIrtual ECH Interim 2 ## September 21, 2020 - 15:00 - 16:00 UTC Scribe: Rich Salz ## Agenda ECH Issues - https://github.com/tlswg/draft-ietf-tls-esni/issues ## Attendance 1 Joe Salowey, Salesforce 2 Sean Turner, sn3rd 3 Chris Patton, Cloudflare 4 Rich Salz, Akamai 5 Uri Blumenthal, MIT 6 Jonathan Hoyland, Cloudflare 7 Nick Lamb, Unaffiliated 8 Eric Rescorla, Mozilla 9 Russ Housley, Vigil Security 10 Carrick Bartle, Apple 11 Alessandro Ghedini, Cloudflare 12 Dan McArdle, Google 13 Peter Wu, Cloudflare 14 Kevin Jacobs, Mozilla 15 Andrew S, NCSC 16 David Benjamin, Google 17 Daniel MIgault, Ericsson ## Notes Topic is ECH. Numbers in the headings below refer to issues in the GitHub repo. ### ECH 274 CAW: Trying to avoid trial decryption. "Trial HMAC" seems to be consensus. The PR now proposes Ben's proposal. (Congratulations to Chris Wood for getting promoted to a TLA :) EKR: Goal is to be "moderately hard" (which is admittedly fuzzy wording). Weakly opposed to addressing Christian's attacks. We can add the defense later by adding an extension to the ECHConfig entry in DNS entry. This is not TOR. CAW: Worth documenting the security goals and defenses (even if not deployed) against that attack. ChrisP: Agree with EKR, willing to consider Karthik's suggestion. If we implement something complicated now, replacing it later is hard. ### ECH 260 CAW: Summarized his writeup of the issue. EKR: This is very good. Change second bullet under goals does protect against active attackers. Sean: make sure to capture anything not in the requirements is captured. Should we be more explicit about what we're not doing? ChrisP: Doc that lays out the requirements is less precise than this. I don't think there's much. Rich: Should use the word "censorship" so that the trade press doesn't put that word into our mouth. CAW: Will make PR, and then we can discuss the use of the "censorship" word. ### ECH 253 PR 292 removes the ECH nonce. Rationale for it is in issue 253. CAW: I have a suggestion about padding, moving from MUST to SHOULD. EKR: There's a separate section on padding, discuss it there. CAW: PSK in outer CH? "Resume connection that's never going to be used" EKR: Just ban it. Jonathan in chat: wasn't there an issue with attacker adding PSK? CAW: Not relevant any more since they cannot affect the inner CH. ### ECH 264 ECH has a mix of padding (extension) and using TLS record-level padding. EKR: Could address by allowing padding in EE message. Alessandro (when prompted by CAW): Impact if compression is just-in-time, even tho you probably know which certificate is being sent. I don't know if that is actually a problem; could add fixed amount of padding. I'm fine with adding it in the EE. DavidBen: I assume you have a target size, subtract cert size. We're looking at RPC to get cert and sign, and this makes it a little difficult but not insurmountably so. CAW: Reminder server-side padding is optional. Discussion of "hiding" RSA vs. ECDSA certs and signatures (ECDSA sigs can vary in size, for example). DavidBen: Okay with this design, but curious why EKR doesn't like adding a new message type. EKR: It feels gross. CAW: Will work on a PR. ### ECH 269 (pull request) Need followup as to why. DavidBen: Expensive; client has three round-trips if server doesn't sync with DNS. Should discourage this. CAW: Servers could mark that they can handle this by adding to ECHConfig. ### ECH 251 Should we have mandatory-to-implement KEM? EKR: TLS likes MTI cipher suites. Sean: IESG is likely to push back without it, since we've done it elsewhere. CAW: Most implementors are doing 25519, even though P256 is in TLS proper. Frederic: Makes sense to do 25519. ChrisP: Should we also have mandatory AEAD? CAW: To draft PR making 25519 AES SHA256 as MTI. ### ECH Summary All other issues seem to be just editorial, so once these are landed we should publish Draft 8, and mark that as a target to implement. -30-