Skip to main content

Minutes interim-2020-tls-03: Mon 08:00
minutes-interim-2020-tls-03-202009210800-00

Meeting Minutes Transport Layer Security (tls) WG
Date and time 2020-09-21 15:00
Title Minutes interim-2020-tls-03: Mon 08:00
State Active
Other versions markdown
Last updated 2020-10-20

minutes-interim-2020-tls-03-202009210800-00

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-