# TLS WG @ IETF 115 - 10 November 2022 {#tls-wg--ietf-115---10-november-2022} ## Administrivia {#administrivia} * Overview of document status for WG documents Scribes: Florence D and Mike Ounsworth ## 8446bis (EKR) - 30 min {#8446bis-ekr---30-min} https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ Planning to quickly rev 8446 to fix some issues. Has taken about 18 months so far. EKR merged lots of PRs, check the change log if you'd like to. Remaining PRs: * 1275 - Unsolicited Extensions - You're not meant to be able to send request extensions in EE, text is being clarified to make this clear. * 1270 - Key Update Limits - Pulling in text for 9147, need to decide balance of consistency v. clarity. If you feel strongly check the change log. * 1269 - Errors for Bogus Tickets - Propose just closing PR * 1231 - Acknowledge RFC 8773 - EKR is going to review this text, would like someone else to review it too. * 1223, 1224 - Clarify HRR Behaviour - It's a bit unclear but it's an improvement over 8446, no better suggestion. Propose deferring these. Martin Thomson: Do all of these things and then we'll be done. Don't want to make substantive changes. Rich Salz: Is it feasible to document the ambiguities? EKR: Very difficult. EKR will finish these things. Sean Turner (ST): Want to move this to Internet Standard. Leaning on group to ensure that features are all implemented. I'll write an small interoperability review. David Schinazi: If IPv6 is a full standard, then TLS 1.3 can be too. ## 8447bis (Sean Turner/Joe Salowey) - 20 min {#8447bis-sean-turnerjoe-salowey---20-min} https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ RFC 8447 currently obsoletes RFC 8447 - this is confusing, hard to review, hard for IANA. Updating would be easier. Any objections? Sean Turner: This document is instructions for IANA, so do whatever is easier for them to understand. EKR: Is the AD happy? David Schinazi: In general I prefer obsolete documents. But here it's not the document that matters, it's the IANA website, so whatever makes sense for them. Paul Wouters (AD): Normally the problem with diff documents is that people don't want to have lots and lots of changes. That doesn't apply here. Joe: Ok, we'll work on clarifying the bis in the coming weeks. Rich Salz: It's not just IANA who cares, this is simpler, we can follow directions either way. Marked reserved values as 'D'. Martin Thomson (MT): Who chooses the SHOULD NOT or the MUST NOT? Joe: Depends on the context. These are only applicable in certain contexts. MT: It's odd to use a registry in this way. Maybe put in something about the linked documents. Joe: I agree. Rich Salz: +1 to MT. Changes to Registry Policy - new text. MT: Is this every state transition? It could say "IESG approval is necessary for all other state transitions" Richard Barnes: I reviewed this and I convinced myself it covered all state transitions. MT: Would prefer it if it was a bit clearer. Joe: So you're saying the last line should be "For All State Transitions IESG approval is Required" MT: All other. Joe: Yes, that would be simpler. Paul Wouters (individual): Is there a reason we're using single letters? ST: No strong reason, just saves page space. David Schinazi: Exporter labels registry is currently specification required. Given it's a string registry with infinite room can we just make it expert review required? Joe: I thought it was only specific prefixes that were extension (specification required?) ...? EKR: You can just generate a random UUID and put things after it. EKR: I'd be supportive of this change. I wonder if we should make it even easier. Maybe we could just say that a document is required. ST: It is sufficient just to have an internet draft that's publised but never progresses or something from another standards body. It just needs to be public. DS: This is why I was thinking expert review. There's no point in saying you have to publish something and that thing can be empty. ST: Submit a PR and we'll review it. Yoav Nir: Let me check standards action requires IESG Approval. Paul Wouters: This came up in another meeting, can a draft be specification to satisfy a "specification required"? A draft gets you early allocation, either the draft expires and your early allocation expires, or the draft becomes a RFC. Need to check this with the rest of the IESG. ST: We've looked at this before: even an expired draft is still public in the archives, so that should be fine. EKR: We're discussing a change to the current policy, which means we wouldn't require a full description of the protocol at all. Trying to figure out some way of encouraging people to document protocols without requiring them to do so. ST: We're currently trying to document first come first served, David is asking if we required expert review. This would be a new policy. DS: You can add a note saying that a specification is highly encouraged. EKR: Purpose of expert review is to make sure people don't register inappropriate strings. Joe: EKR can you put in a PR? EKR: I'll do that. ## Obsolete Key Exchange (Nimrod Aviram) - 15 min {#obsolete-key-exchange-nimrod-aviram---15-min} https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ Draft deprecates RSA Key Exchange and Static FFDH. Limits FFDHE to groups >=2048 bits. Discourages ECDH (static). One open issue. FFDHE groups - clients can't verify group structure because it's too expensive. One suggestion without consensus is deprecating FFDHE entirely. Authors suggestion is to have no requirement around group structure. Question of how much this matters - web clients have disabled FFDHE, while email clients won't very group structure anyway. This issue is the only thing holding up the draft. Strongly recommend moving forward with this compromise. ST: Is there anyone who disagrees with the way forward? Daniel Gillmor (DKG): Who is opposing deprecation here? Don't opportunistic clients have concerns about other TLS KEXs? If you're doing opportunistic TLS surely RSA is better than nothing. If the opposition to deprecation is coming from opportunistic clients then we can have a not about that. NA: The main opposition came from Viktor Dukhovny - his concern was about SMTP clients. Many use custom groups because of advice that was given to operators of SMTP servers. DKG: Ok, so you're saying the argument is that as long as we have FFDHE to fall back to we can deprecate RSA? NA: Yes. DKG: Can't we say that only if the alternative is falling back to cleartext then falling back to FFDHE is ok. No one on the web will fall back to cleartext. EKR: There are browser settings now that attempt HTTPS frst and fall back to HTTP. We would not be interested in supporting these cipher suites, we want to same policy for every connection. What is the scope of this? If we deprecated FFDHE entirely how many connections would go from encrypted to plaintext. NA: Email clients would ignore deprecation, but if they didn't then according the Viktor much of the email ecosystem would become plaintext. EKR: Rather than coming up with complex recommendation, we should write what people should do, and if people are behind then they can not move yet. We should make the right recommendation. DKG: If SMTP servers who only do FFDHE are looking at stats and connections go to cleartext when we deprecate FFDHE then they'll have to implement ECDHE. DKG: That is, if we deprecate it explicitly, and some opportunistic SMTP clients do adopt the deprecation, they will fall back to cleartext. This is a clear signal to the ecosystem that these insecure KEX mechanisms are in use in places where we want better outcomes. EKR: I can't see us applying different properties for opportunistic v. non-opportunisitic mode. MT: Should say opportunistic connections can do whatever they like. Let's leave a carve out that if you don't care about security as a baseline then we don't care what you do re. this particular requirement. NA: So the suggestion is have stringent requirement for non-opportunistic clients, and otherwise do whatever. Yoav Nir: Suggestion is deprecate FFDHE entirely. Nimrod Aviram: So the suggestion is that for non-opportunistic connections deprecate FFDHE entirely or do all checks that make it safe (e.g. group structure). For opportunistic connections you can do whatever you want, or you can fall back to FFDHE. Kyle Nekritz: I'm worried about this carve out, where does it end? What is this issue special? NA: Agree with Kyle. This leads to the question of what counts as opportunistic. David Schinazi: Strongly opposed to this opportunistic thing. We should think about deprecating FFDHE altogether again. ST: Let's do a consensus call. DS: I would propose: option 1: do we have consensus on deprecating entirely? MT: I think we should have option 1: Deprecate FFDHE entirely, option 2: deprecate FFDHE without good groups. Don't think we need to do anything about opportunistic case. The RFC on opportunistic encryption already allows opportunistic clients to use less secure options than ideal if that's the only option. NA: Think we're going towards deprecating FFDHE entirely. Stephen Farrell (SF): I don't disagree with David, but I know that some people do, including Viktor and he usually has good arguments. ST: We'll do a poll but we will then take it to the mailing list. SF: Option 2 "only use good groups" doesn't get us anywhere because it's the SMTP community that want FFDHE and they usually use custom groups. EKR: Opposed to (MT's) option 2 because I don't think it'll work. I would strongly prefer not to have a weird, explicit opt out. Carve out for old clients is in the opportunistic document and also they can ignore us. DS: Sometimes it's hard to update old boxes, that doesn't mean we shouldn't publish the RFC. EKR: The purpose of this document is to tell people in our ecosystem that they should be updating. So if we have an explicit carve out for opportunistic people will think they don't need to change. Yoav / Paul (in jabber): deprecate != disable. Anyone running ancient software is allowed to just ignore our recommendations. Let's do a poll. **Poll: Do you support deprecating FFHDE?** *39 participants. Raise Hand: 34. Do Not Raise Hand: 5* **Chairs will take this to the list.** DKG: I don't think this poll is sufficient to say that the mood is "deprecate entirely". ST: Yes, this gives us somewhere to start. DKG: Want a strong deprecation statement of some sort. ## URI for publishing ECHConfigList (Stephen Farrell) - 15 Min {#uri-for-publishing-echconfiglist-stephen-farrell---15-min} https://datatracker.ietf.org/doc/draft-ietf-tls-wkech/ Ben Schwartz and Rich Salz now co-authoring. draft-01 tries to cater for a wider range of ECH deployment architectures. Background: ECH normally relies on HTTPS records to publish ECHConfigs in the DNS. Want to avoid cutting a pasting public keys into zone files. New version, technical summary: In this version the zone factory speaks to the origin (rather than client facing server(CFS)) Zone factory creates resource records, fetches values from origin. Origin needs to sync with CFS which creates the ECH Configs. Use JSON template to create HTTPS RR. This version makes using a CNAME a bit easier, you can create a JSON blob that eventually turns into a CNAME. Nice but feels a bit dangerous. There's a multi-CDN example. Needs a bit more work but it should work. Other details. DNS TTL needs to be less that HTTP freshness lifetime. Also, ordinary web clients shouldn't use this in place of HTTPS RR. TBD. Exact template matching rules, IP requirements, support for non-HTTPS protocols. SF: Is this a better version that -00? ST: This is better, better to have wider deployments in mind. Ben Schwartz (BS): The template is an attempt to balance competing desires. We want to stick to only talking about ECH and information you need to know to use that. But on the other hand, your zone factory is going to create DNS records that have a bunch of other stuff in them. So we've said let's focus on ECH here, and leave the other stuff to the DNS side. David Schinazi: I like the more conceptual approach. Is you intent that browsers always query this well-known on all websites. BS: The browsers don't know about this at all. The querying client here is the zone factory, which is a component of an authoritative DNS server. ## SSLKEYLOGFILE (Martin Thomson) - 10 Min {#sslkeylogfile-martin-thomson---10-min} https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/ SSLKEYLOGFILE - a file format designed to capture secrets. Used for debugging in TLS stacks and tools. Standardising this needs a home. Currently the documentation for this is in the NSS source docs, pretty hard to find. Idea is to take this documentation, put it in an RFC and give change control to the IETF. Question: Does the WG want to take this on? ST: My understanding is this would be informational. MT: It's an interoperability thing, there's an argument for making it standards track. DS: Yes. Nalini Elkins: Support this work Any plan to say that browsers should implement something like this? MT: No, there's a lot of debate about this. It carries risks to security and privacy, so people are concerned and there are lots of stacks that don't implement it and that's ok. SF: To what extent does the current documentation contain warnings? MT: Documentation just has a file format. The draft has warnings. SF: Supportive of documenting this if there are enough warnings. Deb Cooley (DC): How's this different to PKCS#8? MT: We don't do anything in terms of protecting secrets. If you're operating in FIPS mode you just can't do this. DC: So I don't care. Richard Barnes: This is more like a stream format so you can pipe data straight into wireshark. **Poll: Sense of the room: Is there interest in working on draft-thomson-tls-keylogfile i-d in the TLS WG?** *33 participants. Raise Hand: 28. Do Not Raise Hand: 5* ## Other Stuff {#other-stuff} ### Stalled/Expired WG I-Ds {#stalledexpired-wg-i-ds} * Batch Signing for TLS David Benjamin: I don't have time to work on this now. If someone else wants to pick it up then it's a cool mechanism but I'm not going to do anything. ST: Will let the process do its thing. MT: Suggest marking this draft as abandoned. * Semi-static DH Key Establishment for TLS 1.3 EKR: I'm interested, come back to me when 8446bis is done. ## Encrypted Client Hello {#encrypted-client-hello} Andrew Campling: Anyone that missed the ECH deployment considerations side meeting on Monday evening can catch the recording of the session at https://419.consulting/encrypted-dns/f/ech-on-the-side. (Sorry about the quality of the sound but I think you should be able to pick up the key points).