## TLS Working group at IETF 116 {#tls-working-group-at-ietf-116} March 28th 2023 ======== ## Agenda bash {#agenda-bash} Stephen Farrell (SF): ECH: doing good things; getting interop testing results, but would like to know results about more results. Dennis Jackson (DJ): running tests in Firefox beta/nightly, hoping to publish within a few weeks. Alessandro Ghedini (AG): Cloudflare running experiments; no real issues or broken traffic. No timeline for publishing results. Rich Salz (RS): Has anyone asked the HTTP side of this is? The service based records? SF: In order to get code upstreamed it would be helpful to have an RFC. SPT: To get included into OS things you need an RFC number. It's a balance between more testing and getting it published quickly. Ekr: If the experiments look good, the next thing to do is to "turn the knob". Cloudflare is running this, but we'd like to get more input from other people who are interested in running on the server side. Kyle Nekritz (KN) (Zulip): Meta will have some ECH results in the next couple of months too. ## I-D presentations {#i-d-presentations} ## 8447bis {#8447bis} Joe Salowey (JS) presenting. Any questions for Joe before WGLC? -none- Ok, we'll proceed to WGLC. ## cTLS draft-08 {#ctls-draft-08} Ben Schwartz (BS) presenting. Richard Barnes (RB): there are very early implementations, they'll need updating with the breaking changes. ## Hybrid key exchange in TLS {#hybrid-key-exchange-in-tls} Scott Fluhrer (ScF) presenting. Mike Ounsworth (MO): which combiner function to use will have related discussion in CFRG and likely also in PQUIP. My opinion is that it's fine for the TLS hybrid keyex draft to note that it deviates from CFRG guidance, and why, with security analysis, and that's fine. Martin Thomson (MT): Keep simple combiner is already well documented in this draft about what the constraints are here that justify it. Huge performance impacts to the extra hashing. Bas Westerbaan (BW): in favour of the current combiner. Jonathan Hoyland (JH): Can we not assign a codepoint, but not publish an RFC until we have the final draft for Kyber? Russ Housley (RH): Advocating for more robust combiner: codepoints will come along later that define less robust KEMs, so we should define a combiner strong enough to handle whatever comes later. Note: we only have guarantees about IPR on the final NIST spec. Ekr: RFC should have no Code points, issue draft to allocate code points. Minimizing hashes is nice but not critical (we already have a lot). Chris Wood (CW): consensus to mint an -00 to get early Specification Required codepoints, but otherwise wait for NIST. SPT: on the KEM combiner point, we'll wait for CFRG discussion. ## ECH and SVCB {#ech-and-svcb} Benajamin Schwartz (BS) presenting. David Schinazi (DS): Why did you choose this option between adding this text into the ECH draft vs making it its own draft? BS: As a practical matter I think I did it this way because I could do it myself, without coordinating with the ECH authors. They are also fully separable. DS : Makes sense, I support adoption. AG: I think it makes sense as separate drafts. Don't care if we do it this way or in the ECH drafts. Eric Orth (EO): It all looks good to me. No opinion on separate vs combined draft. Move forward. RS: It should be a separate draft. The target audience is not just TLS but all the DNS community. SPT: Unless there are any violent objections we're going to do a consensus call on the mailing list. Any violent objectors? -none- Ok, we'll proceed with consensus call. ## Merkle Tree Certificates {#merkle-tree-certificates} David Benjamin (DB) presenting. Core idea: sigs in tls are gonna be a wholesale mess to migrate to PQ. The marginal cost to overhauling the whole thing is as low as it'll ever be. This is not a full X.509 replacement in itself. BS: I think of it as "If we have to do merkle signatures for PQ reasons, we might as well unify that with the CT merkle tree". RB: This is similar to STH discipline. Why would this not founder for the same reasons. DB: This cannot be the only mechanism, emergency rekey needs to be possible, for usual cases of renewal this trade-off would be OK. JH: Do you have a mechanism for what signatures to expect? DB: that is the wrong way to think about it, we're not logging X.509 certificate, this is independent from X.509 certs. (ie there are no signatures here). JH: do we need transparency server auditing? How do we detect a lazy transparency server that doesn't bother checking anything$? DB: out-of-scope for this draft. We don't currently solve that problem in CT in general, so let's solve that for both places at the same time. Paul Wouters (PW): Just put the keys in DNS. SF: What's the mechanism to get this to a stable draft state? SPT: we need to huddle with the ADs. ## Compact ECC encodings {#compact-ecc-encodings} John Mattson (JM) presenting. JM: are compact representations useful to cTLS? RB: initially cTLS had some compact representations, but eventually it got too complicated and removed it. MT: We don't need to stop (registering codepoints?) as a result of 8447. This seems like a reasonable thing to do. SPT: anyone disagree with doing this? Ekr: This is conceptually good, but details need to be thought about. The real question is that this is only valuable if people want to do it. SPT: let's give this a couple month break to deal with current WLCGs and revisit this before 117 given that there's no burning urgency for this. ## NULL encryption and non-FS PSK dont-dont-dont {#null-encryption-and-non-fs-psk-dont-dont-dont} John Mattson (JM) presenting. MT: Point of clarification: H2 doesn't prohibit non-ephemeral keyex. Ekr: Two points: 1) now that we're deprecating DHE, we're alreday there. 2) This document should forward discourage NULL ciphersuites. MT: It seems a bit odd that we're allowing so much RSA, but prohibiting ffdhe. Do we have to fix 8447 to say that registering a NULL ciphersuite automatically gets a 'D'? Ekr: You can't register a group. ## Remove packet number encryption in dTLS 1.3 {#remove-packet-number-encryption-in-dtls-13} Boris Pismenny (BP) presenting. Ekr: ports are bad news and lead to the two sides doing different things. Just do it in the handshake. You can register a codepoint for this if you want. SPT: other than the authors, is there any adoption for this? BS: Could you expand on the motivation? It seems like a small gain in AES cycles. BP: we do high-performance computing. The high-performance world generally doesn't do encryption today; CPU performance is the barrier to adoption of TLS, so we're trying to squeeze as much as we can. BS: we should discuss more on-list what is specifically painful about sequence numbers; it seems fairly negligeable. BP: latency and extra state. BS: isn't it equally stateless either way? Yoav Nir (YN): this draft makes a normative reference to the TLS Flags draft, so some process issues. Kazuho Oku (KO): Is there really a need for this? Seems like a small improvement. BP: Yes, we have clients for whom this would make a difference. MT: is that "5%" number from published experiments? DP: No experiments yet, it's hypothetical. MT: I vote against this, do what Ekr suggested (register a custom codepoint?). SPT: talk to the chairs, we'll help you navigate the process. ## TLS 1.2 Deprecation {#tls-12-deprecation} SPT presenting. Rich Salz: Get PCI to do it, because money makes the world go round. (PCI-DSS could ban 1.2). We could put out an RFC that says 1.2 is now frozen. Alex Chernyakhovsky (AC): Wearing my YouTube hat; the problem is clients. There's a lot of deployed set-top boxes that can't be patched. This feels too soon. SPT: We're just trying to get the conversation going, not advocating this (yet). Wes Hardaker (WH): deprecating in the sense that IETF will no longer spend effort updating is one thing, but announcing to operators to stop using it is something else. The Internet still has so much TLS 1.2 (esp. of new devices) that it actually looks like 1.2 is still gaining marketshare relative to 1.3. The messaging here has to be very very clear. Ekr: I think the WG should stop working on 1.2. When used properly TLS 1.2 is still good as far as we know. We could deprecate 1.2 for H/2, before deprecating it for other things. SPT: How long would it be before FF would turn off support for 1.2 Ekr: Below single digit %, so probably less than 10 years, but I wouldn't be surprised if it was 5. MT: Agree with Ekr, TLS 1.2 is currently over 30% so it's not happening any time soon. Greenfield should be 1.3 as a baseline. Cloudflare report a 9% TLS 1.2 rate. AG: Start telling people not to use it for new things. MO: with my AppSecSecurity pentester hat on, we need to be careful to distinguish between "not recommended for new things" and "vulnerable, turn it off" otherwise we're gonna create CVE hell. Tommy Pauly: We need to do more advertising of TLS 1.3. We see about 12% TLS 1.2 over the last 24h. Ekr: Issue some statment that say: 1. We're going to stop updating TLS 1.2 2. Use TLS 1.3 for greenfield 3. We'll be monitoring usage and will deprecate it once usage gets low enough. Rich Salz volunteers RS: Will the draft also say we won't accept IANA codepoints for 1.2 Ekr: that would be a mistake because then you'll just get un-authorized codepoints that clash. Viktor Dukhovni (VD): Raising the ceiling seems to have worked pretty well. JM: what about dTLS 1.2? Ekr: John's right, dTLS 1.3 adoption lags TLS 1.3, so we need to be careful about deprecating dTLS 1.2. Fine to not accept new features.