Agenda IETF 106TLS Working Group Agenda Saturday and Sunday, 16/17 November, 2019 8:30 - 16:00, Moor/Morrison Notetaker: Tommy Pauly Request to move semi-static after extended key schedule. Working Group Drafts Importing External PSKs for TLS =============================== Chris Wood: Changes from -00: Changed to be more specific about the protocol that is used for imported identities. Added opaque field to defend against Selfie attack. Started work on formal analysis. PR open to describe Selfie attack Mohit: Some people thought this was a misconfiguration, but I provided another example to describe the problem. If people want to have secret communication, and they exchange a secret, it's vulnerable to selfie attack without the attacker knowing the PSK. I disagree with Martin Thomson that this attack requires some additional signalling. Martin Thomson: I forget what the signalling comment was specifically. To address the core question, I think the comment is on the text more than the design. We need to understand what's required to do this. I think the proposed change can cause a regression in privacy. Mohit: Even the previous text mentioned identities such as MAC address. If it's only between two parties, you just need to make sure the address isn't shared. Would like the WG to make a decision on this. Chris: I mainly want to ensure we don't regress anything. Jonathan: We need to make sure that people don't assume that role and identity are in some way tied. People suggest putting "client" and "server" instead of name, which doesn't fix anything. Make sure that things are always different, not necessarily always unique. ekr: The idea here is to start with one PSK and move to N^2 PSKs. In some unspecified way, figure out what key to use. The current text punts on the problem to the application. The proposed text is somewhat confusing and worse. How are the identifiers used? Chris: Yes, the document does try to punt on this question Ben: We were thinking a lot about resumption PSKs and not external PSKs before. My suggestion is to have a standalone document to describe considerations for how to USE the PSKs to avoid various attacks. Chris: I want to keep a reference to the selfie attack. I don't think we need an errata on the existing RFC. Martin: I was going to say the same thing as Ben--have a separate document. We're not ready for that in this document. This is not for an appendix. Sean: Are people interested in joining a design team for this on a new document? (Several hands go up) ekr: There are two modes of issue: being confused between client and server (solvable problem by separating what keys you use as each role); and the other problem of having multiple other parties (N-party), in which case you use more identifiers. I'd suggest that we remove all of this material. I think we should reject the PR and maybe strip down the existing text. Sean: We will reject the PR, and form a new team to look at this. Mohit: I want to sleep on rejecting the PR. Fine if there is consensus. My quibble is that if we are going to add identifiers to this, we should have some text to describe what to do about the Selfie attack. Jonathan: It boils down to: do you trust everyone who has your key. (Debate cut off) Chris: Other open PR is to change key binder computation. Not sure if it's needed. Jonathan: I think it's needed as a general thing, not sure it needs to happen here. May fit better in the other document than here. We should use binder labels but define them in the key schedule document. ekr: I've concluded that we do have to do this. We've had too many complicated attacks on this kind of thing. Hannes: I am uncomfortable about making changes like this based on gut feeling, that adds complexity. Chris: There is a case in which this is potentially a problem, so I think it is concrete enough. Martin: It's not very clear what the structure of the imported identifier is. The intent is to import it in the structure mentioned? Chris: Yes, please file an issue. Exported Authenticators ======================= Nick Sullivan: This document has gone through last call reviews. One last point raised by SECDIR. Client-initiated server auth for an extra certificate is possible using an authenticator request, mirroring the certificate request, and has an exported authenticator. The set of extensions currently allowed in this uses the server list from IANA. So this isn't allowed for clients. The suggestion was to have the document update RFC 8446; or else spin out a new extension point for SNI that's not in the client hello; or treat the cert-request-like structure like a client hello, and use client-hello extensions. So we have three proposals. Martin: I think this is the right approach. We started pulling about extensions and their roles, and there are multiple types of extensions in the client hello. They have different purposes. The third way is the simplest. Kyle: Would it make sense to treat this as a different message? Nick: If so, I don't think we need a new column in IANA. Ben: I like the third option, but if you put yourself in the shoes of a bad server, what could happen if they just process whatever client hello extensions. Nick: Yeah, may make sense to have a whitelist. Jonathan: Would we have to ignore mandatory extensions? Nick: We wouldn't have any such mandatory requirements, it's not about expecting a full list. Jonathan: Yes, do a whitelist. ekr: I don't like the third option, to the point that Ben made. We can discuss how to express this. I am OK to update 8446. Nick: What about just whitelisting SNI? That's the only one we need. ekr: I'm not sure. Chairs: More discussion required. Please chime in on the list! Delegated Credentials ===================== Nick Sullivan: Also a proposal to add algorithm flexibility to advertise a set of supported algorithms to be used for delegated credentials. There's a dual use of the algorithms. Martin: We struggled with this in RSA PSS. We have multiple pieces of stack and policy that need to support this thing before we turn it on. At the point we turn on PSS generally, we can turn it on here. I'm OK with this proposal. Having a small set of schemes for delegated credentials is a nice picture. ekr: I can live with things are they are, or the change. It's a beauty contest. Does anyone feel strongly on one side or the other? Kyle: I realize there's a use case, but will anyone use this? We wouldn't. No problem if someone does... Martin: Let's not add something that we don't have a use case for, but there seems to be a good one here. It's nice to be able to experiment with some of these algorithms. Sean: Seeming like we should accept this proposal. Hannes: On a separate issue, the max lifetime of a delegated credential (7 days) seems to be random and a little short. Nick: It's a max based on typical deployment of OCSP. Martin: This is coming out of the web deployment. Maybe say "absent other information, should be 7 days" but let it change for other deployment models. Hannes: IoT devices can benefit from longer period here. Ben: I'm not sure there's a web context that's identifiable to the server operator; they don't know what kind of client they have. You could signal a max in the client hello to indicate this. Martin: This gets into a vague area. Not sure if we're making this worse. Kyle: If we don't have a MUST in here, what do we do if the lifetime is beyond what the client will accept. ekr: I would suggest that when we understand the other uses, we add some signalling mechanism then. Hannes: Specifically, in the TLS spec, we explain that things are mandatory to implement, absent another configuration. Specify 7 days UNLESS some other need. Subodh: Can we get an early allocation? ekr: It's already in FireFox Sean: Yes, we need an early allocation then. ekr: We need something like QUIC has for provisional allocation space. I can work on that. TLS 1.3 Extended Key Schedule ============================= Jonathan: TLS has nice properties, but may we want some new properties, like privacy properties for clienthello, or hybrid quantum keys. Can we add these without breaking things? We know that TLS has properties based on analysis. Modifying the key schedule may mean we need to reanalyze everything. How do we extend key schedule without breaking things? There are many drafts that want to change the schedule, such as: hybrid key exchange ESNI External PSK Semi-static All of these modify the key schedule in different ways, and don't have analysis of how they combine. Many dragons lurk here! This draft attempts to catch these changes and define a framework for making this composable. Defines a few points to inject into the schedule that are safe. One for PSK, one for extra secret before D-H, one for master secret extension. To clarify, the labels in these additional injected values are important (based on discussion). Have an IANA registry for the fixed order of how to add new secrets. There is an alternate proposal to use the fact that HKDF can take two inputs, but makes the key schedule non-linear. Martin: You could also just concatenate things. We have in most implementations the ability to switch out the input to HKDF-extract, rather than inventing new joints in the protocols. The concern that this is trying to solve is valid. ekr: The current schedule has one secret insertion points. Trying to have more inputs shows the original problem. I also like the concatenate option. Let's let the crypto people suggest what to do. Russ: Does this affect early data or not? ekr: For any case where we have an input into the schedule, we could change it from 1 to N. Hannes: The schedule became more complicated into 1.3; and we are making it incrementally more complicated. Can we work on the proof to allow the implementation to be simpler? It's a lot more code, which adds risk. Russ: This is very interesting but also complex. The key schedule is the core of 1.3. This looks like 1.4. Jonathan: Should we not do any of the extensions like ESNI? Sean: Let's take this to the list... Daniel Migault: This is a major change. Let's be careful. Compact TLS 1.3 =============== THESE SLIDES ARE APPALLINGLY GREEN ekr: What are we trying to solve? There's still cruft in the TLS handshake due to legacy that can't change. Why does QUIC have to use legacy version numbers though? From the beginning of 1.3, there was concern about the feature set being too rich. What's the minimal feature set that easier to reason about? Also helps make the implementation smaller if we can simplify. Various use cases: QUIC, ATLS, LAKE, EAP... - Clean up the handshake messages (use varints, remove unnecessary fields, remove redundant message lengths) - Specialization Mechanism (not everyone wants all extensions, create more slimmed profiles). Remove unneeded extensions, but allow extensions. Signal a profile that you want, with variation. - Predefined extensions. Initial numbers show a good win of bytes on the wire. Goes from 1K bytes to 300 bytes for ECDHE. QUIC had separated handshake and records; but this wasn't formal in TLS yet. This change makes that formal, and defines the interface strongly. Have people read this? (couple dozen hands) We'll need to change the charter for this Daniel Migault: This is not the first compression. We should work with LPWAN. David Schinazi: As a question, you mentioned QUIC as a use case. This is for a future QUIC version, right? ekr: Yes, and. The separation supports what we did in QUIC. If we change the format, that's for QUICv2. Change the charter. Valery: Important work. We should work on it. Profiles seem to be out of band, and need to agree on profiles. What do we do when a profile needs to be changed? ekr: I agree this should be solved. Still working on ideas. Tommy: Strongly support adoption. Not just trying to make the protocol smaller on the wire, but make the protocol more attractive to many new use cases that don't need previous overhead. Chairs: Two hums. Do you want to adopt? (Strong hum) Do you not want to adopt? (Weak hum) Ted Hardie: I think we should decompose this work. The retconning of the layer separation is much easier. You can get parts done faster! ekr: Happy to defer to the group for splitting. Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 ======================================================== Bringing this document back after London, due to compact TLS interest. The semi-static case uses a static key share, mixed into the key schedule, and replaces the cert verify with a MAC. Key schedule change refers back to Jonathan's presentation earlier. Martin: I am worried about this changing more in the protocol than what it intends, since implementations may not be prepared to add items it at this point in the schedule. ekr: If we don't care about the benefit of mixing server key into the master secret, we'd be okay. To support client auth, we don't mix them. That's a little goofy. Karthik wanted to keep the structure, I think that's good to do. Jonathan: Is it obvious that this gives you the same guarantees as TLS 1.3? ekr: I believe it does, but we need to confirm. It is intended to. Hum for pursuing this topic: (strong) Hum against (some, but quieter) About 10 willing to review 5 willing to write text Batch Signing for TLS ===================== David Benjamin ekr: This is cool, like the merkle tree. Can you contrast this design with just using a DC for a very fast interface? David: You'd have to deploy new DCs frequently. It's true that that would get you some of the benefits. ekr: I am supportive of this, just wanted to check if it's still useful with DCs Martin: I think you can avoid the full hash for the blinding. And, did you consider minting another kind of certificate verifying? DKG: You mentioned it may leak info about load. I think that can be avoided. Thanks for including the blinding. Ben: This seems good for slow post-quantum signing. Christian: Very cool work, but makes me sad. Pushes towards more concentration on big servers. Kazuho: I think this is a good idea. Changes cost from O(N) to O(1). Hums: Are you interested in working on this? Good hum Will you contribute? 6 hands Do you want to adopt this? Strong hum Do you not want to adopt? No hums ================================= ================================= Thursday, 21 November, 2019 17:40-18:40, Thursday Afternoon session III, Canning Note taker: Joe Hall Well-known URIs for ESNI ======================= slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-tls-farrell-106 draft: https://datatracker.ietf.org/doc/draft-farrell-tls-wkesni/ Ben S: likes it, imagine you have to change something in the Master to do this A: cron job that does this hourly. Ben: do you need the .well-known or can you tell the master "here's the URI"? dkg: I like this. your DNS auth server will check, should the client check too? Also, this should specify some sort of MIME type and register it? A: yes Tommy P: interesting, should explore if we really need .well-known for this when asking a server for the keys for a given name? A: in sftcd's setup, he just knows. David Schinazi: interesting, this is a server-wide policy EKR: what are the semantics of this in multi-CDN use cases. A: Not clear. That should be resolved. I assume CDNs would need to do something to resolve this. PHB: Think that this might be problematic. At the level of ESNI auth, Talking about keys that are with the HOST connection not the service, may be a conflict DKG: This draft should specifically state if this is an exclusive list or additive list. Sean T: Please do a rev and we'll take it to the list and resolve before next IETF. Deprecating MD5+SHA1 ======================= slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-tls-md5-sha1-deprecate draft: https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/ Only one change: MUST abort handshake Allesandro: even though some can't actually disable MD5+SHA1, we should move ahead. Sean T: Would like to proceed with WGLC. TLS Ticket Requests ======================= Chairs: Sense we got was that people want this to be published with a SHOULD and we're ok with that Sean T: There was one issue in this draft, will do a 2nd WGLC on just this one issue. Tommy: Pointing this out and the confusion it generated was good to see and resolve. Sean T: Will take it to the list and point to the PR that does this and ask for objections. Encrypted SNI ======================= slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-ietf106-tls-esni draft: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ (PR200) sftcd: you can still have multiple RRs right? A: sure. (PR 201) Alessandro: this is how we imp'd ESNI. Wouldn't change anything for us... wouldn't simplify. sftcd: I'd be for flattening, get rid of the complexity Kaduk: depends on how many keyshares you have Tommy p: does anything stop you from doing one keyshare per ESNI? A: No. The point is the client imp negotiation has to iterate over keyshares. David B: Don't care much about this one. motivation was looking at sftcd's draft... the representation of the server was a double list structure. It got annoying. If you flatten it, it is a list of public things and private things. A: we deserialize the structure and negotiate things in sequence. Store some stuff and then come back. Ben S: the only signifincat thing that we're talking about duplicateing is the fallback thing. The ESNI config bundle is still only scoped to a single IP pool, so if you are in a multi-CDN case you'll need multiple RRs. It's a little silly to replicate the fallback name, this seems weird Sean T: we need more discussion on the list about this. Sean T. On WGLC, need to get eyes on 201 so we can come to conclusion sooner. EKR: We can't go to WGLC without substantial analysis sftcd: What's the question marke on HPKE? A: We're using some weird stuff that is psuedo-HPKE. sftcd: Would support the HPKE change here. Richard Barnes: HPKE is about what you need and should be ready in time. EKR: If we don option 2 we'll need to an exporter from HPKE Barnes: Should be straightforward. Tommy: As a bikeshed, when we talk about encrypted ClientHello, do these options require a full CH? Ekr: good question... this is a matter of intution... mine is to get it all in there as when we've done less we've been sad. That is, generate completely fresh CH. Concern that we may be duplicating things. You only use one or the other of the innards. Tommy: e.g., in IKE there is a lot of precedent for encrypted stuff Nick Sullivan: early data is not in the CH Jonathan Hoyland: (something about decompression?) If you have no interior CH, and just have key that is used to encrypt the extensions... easier to reason about who has that key Wes H.: Encrypting turtles all the way down. Protocols have a horrible time with complexity when imps get it wrong. I would want to imp both and see what got me more code reuse, etc. Richard Barnes: seems like if we're enc CH, we can enc the Server Hello... then it's encrypted Hellos all around. Ekr: has the benefit that you (? don't have to tunnel encryptoin) Deb Cooley: CH inner and outer. Have the inner which we had originally, encrypting the inner. Will you force validation between the two? Ekr: random values will be completely different... if you don't do the compression trick, Kaduk: imagine a world where the outer CH is fixed except for the encrypted bit. Outside is just in case you have to fallback. Deb: reminds me of SP3 where we did encapsulate... had to be careful of how you did it and had things in both places. If you have values in both places you have to make sure values in both are the same. Ekr: here we just ignore one or the other... in trivial case KeyShare only in each. Deb: writing a check, you put the numbers of the value of the check, and then write out the words of the value... those should match and if you don't problems. Ekr: here, we don't care if they're the same.. and one depends on the other so they have to be different Deb: is there going to be a way to not do this? Ekr: many people will not do it. Ben S: like cTLS, could treat inner and outer as reconstructed... would put them into your transcript Ekr: that's what's supposed to happen. Ben: your outer ESNI value could x x fingerprinting resistance DKG: Thought on Barne's suggestion to encrypt Server Hello... not sure we'd want the ESNI acceptance signal to be observable. Ekr: the only real reason is you can probe accepted vs. rejected. Dkg: the work that is going on in LAMPS about protected email headers smells like this. Tommy: Concerned that if we say we're going to ignore them but they'll probably be the same, that's not going to work. We need to think about the consequences of this. PHB: Had a solution built on IP-based cert but realized those don't exist. Nick S: (IP certs do exist.) The two options are not necessarily different... 2 can complement 1. Let's go forward with 1... option 2 can be implemented as a separately. Jonathan H: with the injected key you know that the backend server knows the injected key... the reasoning is simpler because you know the other side knows the key. Sean T: We'll take the Charter discussion to the list.