IETF 96 Transport Layer Security (TLS) Minutes Date: Tuesday Morning Session, July, 19, 2016 Location: Berlin, Germany Chair: Joe Salowey, Sean Turner in absentia. Minutes: Jim Schaad ============================================== Administrative Trivia: Done with success. Document Status: DKG (Daniel Kahn Gillmor): Should get Auth48 done soon YN (Yoav): 4492-bis - new version recently. Maybe ready for last call. May need to wait on CFRG KP (Kenny Patterson): Getting close to EdDSA being done. Some implementation details need to be ironed out. TLS 1.3 Document update - EKR (Eric Rescorla) Called out change in warning level alerts where I am not closing the session. Call out a note where server cannot wait for the end_of_early_data message because of potential dead lock. Want to allow client to continue sending data until it gets the server hello. MT (Martin Thompson): Post-Handshake Key Separation - What is here is great. No additional discussion on this issue. Cipher Suite Negotiation: (Break Up Monolithinc cipher code points)1 MT: Allows for post-quantum by just defining a new named group. EKR: Lose the ability to express some combinations where specific things MUST be linked - example of Fortezza given. MT: Can still make some decisions in the server to remove options based on other selections. I.e. P-521 might eliminate 128-bit AES. DKG: Offering static DH and no signature. - call that static DH signature? Becomes less orthognal of mix with signature algorithms ??: EKR: May not be supporting some of the JPAKE type algorithms in the future STP: Are we still supporting the not recommended column in the registry? MT: In terms of PAKES - separate exercise for supporters. David Benjamen(DB): Can still use extensions to do strange things to support. Russ Housley (RH): hash in signature and hash in PRF are distinct in the choices. Can result in mismatches of the hashes EKR: That this a feature or flaw depending on how you look at it. EKR: Client must offer a consistent profile if needed. ??: Why negotiate the PRF here. Make it separate EKR: Does not seem to add a lot of value. But yes could do it. Yaron Sheffer (YS): If forcing to send multiple proposals - might be good to say that this is a proposal but other proposals exist. EKR: All ready can say incoherent things today. DKG: want to think about version - do they mean things between 1.3 and 1.2 EKR: No these are empty intersection groups. MT: Have that problem already today with existing suites. Some today are already version restricted. Commit to version and then go from there JS (Joe Salowey): Sense of the room is this is a good change PSK Suite Negotiation MT: Gives a chance for implementations to add some checks on where and if entropy is being added to the system. EKR: This is another orthogonal (more or less) piece the the rest of the Chinese menu on the previous slide. EKR: Allows for PSK for client auth w/ server signature for it's proof of id. EKR: Treats PSK as special case of resumption. RS (Rich Salz): How is this being configured? MT: Have stuff in NSS that allows for this to deal with ordering and turning on and of each of the items individually. DB: Probably want to do some type of post process extract for dealing with backwards considerations on ordering. DKG: Wondering if implementers could look at and present a string version of how these should be represented for both client and server. Lead to consistent representation. Dev: How are the security considerations for this is going to be done? Making things same-ish DB: Don't need a language unless you want to do some matchy-matchy things of grouping. DKG: Standard string format makes cross implementations easier to deal with. SF (Stephen Farrell): Might want some type of "enough" or turn off capability to deal with algorithms going bad. HUM: Do you support this change? Substantial Oppose: None Version Negotiation DB: Want to do this for a large number of the lists. Burn some section and check for errors by sending some strange things on a regular basis. MT: Want to stop after the first bullet point. Version upgrade based on some extension being present and make sure that all new versions of tls have a required new extension defined. DB: I can be happy with either method. EKR: New extension would not allow for preference order. ??: Would allow for an indication of that middle versions are not supported. I.e. 1.0 and 1.3 only. EKR: Allows for unofficial forks by using unregistered values. EKR: The old max/min pair never worked. Erik Nigen(EN): How much of the negotiation is sever vs middle boxes. This is going to be worse for that for now. DB: Intolerant middle boxes seem to be all gone and hopefully will stay that way. DB: May still be problems on version number checking. ??: Extension marking will not work if only want to do 1.3 MT: Will not have anything in common with the server and fail. For current time can disjoint cipher suites Andrey Popov: This can be a UI problem as the missing in the middle items might be a need to show it in the UI. HUM: Do you favor changing the current negotiation mechanism? low hum Oppose: Relatively large hum PSK and Client Auth Hannes (HT): Confusing because two types of client auth. PSK w/ session resumption client auth makes more sense to re-prove. ??: Makes implementation harder -need to remember previous state harder. Do you need to get a cert after end of client data. Rather than be in a state of expect client finish or client cert vs only expect client finish. EKR: Agree - had the same issue as well. EKR: Server can prove it still holds key via signature but not for client until post finish. EN: Makes it harder to deal with the case where a holder of the session ticket key can do faking of any client. Sad that one of the mitigaters is going away. DKG: That is a very bad situation anyway. Not a great deal of sympathy. Chair: No objections to doing the ban step going forward. Resumption Contexts and 0-RTT Finished. A (Antone Delignat Lavaud): Currently an attack in the current draft about this. This is only for external application PSK. EKR: Does the attack require sharing keys? A: Yes MT: How do you decide on the PRF hash in this context? MT: Need a finish for all of the PRF hash and PSK key pair in order to do the FINISH at the end of the extensions. EKR: This is a problem for the non-zero RTT Mode A: There exists a method to generate a resumption context which matches the resumption case for the PSK case. Chair: Need to have a discussion on the list for this issue. Multiple Concurrent Tickets MT: Not sure what properties we are looking to get out of this. EKR: Looking for the set of tickets which are currently valid Could just set a list of tickets still valid MT: Flag which says all previous tickets are dead. Prefer just dump a lot of tickets and suggest use the last one. DKG: Multiple tickets are needed to prevent linking. Need to send note when server state has changed so state associated with a ticket is running. Example is mid-stream client auth added to the ticket state. MT: No value of doing cross session invalidation of tickets. EKR: Could use a ticket extension later if needed. AP: Batch replacement of multiple tickets would be a workable solution EKR: Can live with this, for this connection. MT: EKR is talking about how we do this today on browsers. Blow away all old tickets from the same origin when new tickets come in. Could change this in the future, but why bother? EN: Another use case is better key rotation practices. Would allow for different keys per cluster. Keeping the semantic of multiple alive helps here even if it might hurt privacy semantics MT: We have now identified the bike shed and we should let a small group start painting it. Last-minute thought: EE in Second Flight MT: No this should be done with new handshake messages and since we don't have use for it now. EKR: Neither do I. Chair: will need list discussion receive_generation field in KeyUpdate - Keith Chair: are there objections to this approach? DKG: Seems to collapse two semantics of - I am using new key and I have delete old key. KW: On receipt it is required to ratchet keys forward. No reason to keep old key. KW: Key is no longer usable for trusting incoming traffic - do not use not it is delete. EKG: The key could be leaked to a third party and they can learn history, but cannot produce new traffic. SF: Not sure that it has been properly discussed on the list. YN: it is a TCP stream - why is the number needed? MT: Saying things about the opposite flow of data - what the other side is doing/has done.