Agenda bashing Stephen Farrell: why are we here considering there was “no consensus” Joe: There’s interest and different technical approaches. Kathleen: Support chairs, trying to determine if there is a way we can move forward without strong technical or other obligations. Ted Lemon: Perhaps we focus on proposals that don’t haves strong technical objections Record Header Extension Ekr: If you have the CID, you can look up the state, and you can put whatever you want after that. Why do you need a generic extension mechanism that’s keyed off the header? (We’re doing CID-based state lookup in QUIC.) Two different designs — one that is packets that are self-describing, and those that are not. Ekr: Things shouldn’t be in the packet header unless they are needed to interpret the packet (header). DKG: Seems like SPUD moved one layer down No — SPUD was not about endpoint-to-endpoint after negotiation. DKG: Similarity is that it’s arbitrarily extensible outside encrypted envelope. We decided not to do SPUD. MT: This helps with packets that arrive on different 4 tuple than original connection, and there are no expectations about whether or not packets have CID. (That seems rare.) Clients and servers that care about this problem will likely use CID. Maybe not care about those who don’t use CID? Want to avoid wasting cycles to filter trash packets. MT: In what environment do you not have to deal with trash? IOT for the moment (?) Hannes: (missed) Ekr: CID on Wednesday, this is strictly about the extension proposal Proposal for generic extension mechanism Tobias Gondrom: Like the idea, though don’t necessarily need the generic extension mechanism. TLS Visability: Stephen: Can you explain “many” in this context? Nick Sullivan summarized a different approach, and others discussed on-list Stephen: Who receives the key? More than one party? Ted: Can the key manger send the key to more than one peer? Yes. Stephen: Does that meet the criteria? Ben Kaduk: Does this need to be negotiated, or can parties just agree to do it? People who raised concerns and want opt in objected to draft-green, which was between server and key manager. This new draft resulted from that criticism. Ben: Extensions used to negotiate protocol features. In datacenter you know if you’re talking to a specific peer, with a specific implementation, so you can decide that between a given set of peers a specific thing will be done. It may or may not be TLS. Why is this in-protocol negotiation really needed? Doesn’t out-of-band agreement suffice? Can’t you create a TS-like protocol that allows this visibility. That would be another design choice. Not the one here. Darren: Continuity in topic speaks to the need of datacenter decryption. We’d like to ask for a vote forward for this. PHB: Agree that this is important use case — in SCADA (?) world. Big concern in some applications is integrity, not confidentiality. This protocol does not have the right degree of control, so I filed a patent on the new design. Yaov Nir: Draft proposed online decryption only. Do we need offline or online? Could make the case that anti-malware doesn’t need online keys for analysis, as it should be higher up the stack. Not sure why we need this feature of the protocol when passive, offline decryption is needed. We’ve looked at cases where real-time decryption is needed. Nick Sullivan: Does this offer the ability to compute exporters? Yes. XXX: know that large providers do use packet flow analysis for cybersecurity reasons. Authors have listened carefully to draft-green concerns, have addressed them and found a technical solution that addresses privacy on the open Internet. Steve Fenter (?): After-the-fact decryption is useful for troubleshooting. There are a number of uses for live decryption, e.g., application performance monitoring. Metadata is created and packets are thrown away. Fraud monitoring is another example. For large complicated applications, it is effectively to insert traces in many places and help debug. Stephen: How would you characterize this work in analysis between 1.3 and the work that went into the analysis of this draft? TLS 1.3 went through analysis, there is no analysis here yet. Stephen: Would you not agree that formal analysis is necessary? Agreed, the same level of analysis is needed if the WG wants to go forward. Stephen: Analysis says that this extension is a bad idea. Shouldn’t you do that first? No, we can do it as we work on it. David Schinazi: Can you clarify what clients and what servers are being used? Are they data center hosts or servers? Load balancer, e.g., is client. In some cases client is outside the data center, e.g., a POS terminal. David: If it’s purely datacenter, you don’t need TLS (or this extension). What is the point if browsers do not want to implement this? Absolutely. Ted: Number of distribution points that receive keying information will not be one. State actors might require operators to share keying material within territory for future analysis. This type of attack must be taken into account in the analysis. Only foreseeable way to address that is to share identities of all listeners in the technique. Leads to increased complexity. DKG: Thank for your acknowledging that the goal is not strictly within the datacenter. Client opts into sharing with someone — anyone (key manager). Does the client have any way of knowing with whom the key is shared. That’s what Ted said previously. DKG: was that intentional? Yes, we can revisit. Kathleen Moriarty: Still hearing major concerns that could be enough to block consensus standpoint. Would like to see if there’s a way to constrain to datacenter use case. What if this was server-to-server in datacenter only, and clients terminates with LB or another entity on the boundary. Can we constrain the design as such. Do not believe this is a fruitful way forward. There are use cases in different enterprises where clients will not be LBs. Brian Witten: It sounds like you’re open to the approach where client authenticates the key manager. Yes, willing to discuss. Brian: Clients on the open Internet do not accept this visibility, and employers when connecting to their own network do accept it. Adoption? Ben Schwartz: Sounds like one purpose is to guard against data exfiltration attacks. Does not seem technically fit for that purpose. Attacker who manages to break in can exfiltrate all plaintext traversing the network. XXX: Share concern that this might increase attack surface area. How much more costly is this than doing opt-in via cert installation and active MITM? Charles: Out-of-band decryption is highly prevalent in enterprise circumstance. SIP endpoints need it to help troubleshoot. Healthcare endpoints need it for (?). Stephen: Can you explain how breaking TLS like this is in the scope of the WG charter? It’s a TLS extension. Stephen: Do not believe WG was chartered to support this type of functionality? Perhaps we start by re-chartering? Kathleen: Are there other mechanisms that might be more agreeable? Adoption hum: no consensus to adopt. Authors must go to the ADs to proceed next