IETF 91 TLS WG Thurs Nov 13 0900 - 1130 Chairs: Joe Salowey and Sean Turner Notes: taken by Paul Hoffman, didn't copy text from the slides ------------------------------------------------------------------------------------ Three documents might be adopted in the coming months Current docs RC4 deprecation General agreement that it needs to happen, disagreement on when Session hash WG LC is soon Downgrading SCSV Very close to finished with WG LC Martin Thompson: still questions of how the step-by-step is done Maybe specify what version you tried and failed Andrei Popov: Would like this to be an extension Ekr (Eric Rescorla): There are only a few things, so we can just make a few SCSV Martin: Already shipped, and is willing to live with the current limitations Ekr: Are we going to break IE if we support this? That would suck Andrei: Can live with the current draft Martin: Their numbers show the step-by-step is stupid Joe Salowey: Will be another WG LC on this More people mentioned other weird cases Cached Info Hannes Tschofenig made some real changes in the last round Wants to be sure that AGL and Ekr are happy with the changes Finite Field DHE negotiation -- Daniel Kahn Gillmore (DKG) draft-ietf-tls-negotiated-ff-dhe Most people on the list wanted a baseline of 2048 bits Different use cases for what needs to be protected Dropped 6144 to reduce fingerprinting Tero Kivinen asked about security proofs DKG has them Question is where to publish them Sean suggested IANA, but maybe somewhere else Stephen Farrell asked about reusing IKE groups Daniel (DKG): some people wanted each Sean: this will come out in WG LC Indication of client support If the client indicates what it does know, but none that the server knows, it doesn't know how to proceed Martin: have you considered having a signal to which it knows? DKG: that can lead to silly states or confusion Martin: the server must not negotiate FFDH without one of the groups that the client said Rationale is in the draft Server selection indicator Number of bytes isn't all that significant Alerts Questions about what they should say Sean Turner: WG LC will ask again if people want IPsec numbers or new ones OPTLS Recap -- Ekr Nico Williams: If most TLS 1.3 connections are resumptions, is really useful? Dan Harkins: Does the need for generation go away if you have an DH cert? Ekr: Yes ?: Delegation means more than just handing off a key Chris Newman: This would be very useful for secondary MX hosts in SMTP relay Mike St. Johns: Is the main impetus for this lack of support for ECDSA? Ekr: Can't speak for others, but this isn't needed if there is a lot of ECDSA around Phill Hallam-Baker: Wants to be sure that doing the ephemeral doesn't weaken the the rest of the strengths Impact on server compromise depends on whether you are using HSM Some scenarios can turn into a long-term compromise Hugo proposed two different types of keys this morning DKG: Would we need to define a new PKIX EKU and get them deployed? DKG: It is hard for us to discuss this if we don't have a specific use case with assumptions Yoav Nir: Could create a new certificate extension Ekr: You also need to convince CAs to issue those Erik Nygren: Can this be done as a new ciphersuite? Ekr: That would be easier with the second flow presented Structure of data could be complicated People thought a lot more scoping Dan Harkins: Doesn't this mean that the client needs to predict the group? Ekr: this requires the server to generate subcerts for every group it uses Paul Hoffman: Mostly concerned about the unclarity of what is needed in the data structure Joe: If we are going to design a delegation mechanism, we should do that very consciously DKG: TRANS WG wants auditing for anyone who can act like a CA, and this looks somewhat like a CA Sean: These certs might be self-issued Andrei: Management of the pseudo-cert is lots of extra complexity that can lead to error Martin: Very very hard to get this right Not enthusiastic to do that much work Potentially worth doing later as a new ciphersuite but we should continue on our current 1.3 work Nico: RFC 3820, proxy certs, are sub-certs Dan H: This has a lot of cool properties, supports it Likes the idea that one exchange can be used in a multitude of environments Martin: We already have one way for those Sean: Rough consensus to not do this now Compressed point format Proposal: every new curve comes with a format All current would use uncompressed points No more point negotiation Will merge this pull request Removing renegotiation Will merge this pull request Session hash, issue 63 (Mostly the same discussion as on Sunday, see earlier minutes) We need two key generation phases, the question is how much of the transcript exists Jim Schaad: Is this before or after the certificate verify? Ekr: We are being more aggressive, not less All the handshake stuff is based around the master secret Martin: The client now controls the use of resumption Ekr: 1.2 and earlier the server always generated a key, and someone could use this if they broke the session hash DKG: Client can also control the number of times it is reused Very few people have read the pull request Mike St. Johns: Still worries about key reuse, keys should be single-use Ekr: Can do this Martin: Handshake traffic keys are bi-directional Ekr: Let's talk about this later Russ Housley: Likes the hierarchy that is coming up, needs to think more Mike St. Johns: Using PRF in too many ways Ekr: Needs to rationalize the uses in the text Sean: Ask for WG response in the next week Issue 91: Renegotiation for key refresh "Update" exchange Responder must ack, even if they don't understand it This is used to get new traffic keys Can be used to crank the PRF But there could be race conditions Two different key ladders, one for what you send, one for what you receive Paul: More complicated than it needs to be. Only one side should be able do it. Martin: Disagrees that Paul's idea is simpler. Either side might feel uncomfortable. Erik: Other side could say "please crank now" Yoav: Are we worried about the nonce space depleted? Ekr: It's 64 bits, so if you use randomly-generated ones, it's smaller Hannes: This happens rarely Issue 93: WIP Session Resumption For tickets, server doesn't need to hold state Session IDs can be issued earlier in the handshake Proposal: unify them Sam Hartman: TEAP assumed that tickets would never change May need an update for 1.3 Jim: The master secret needs to know about both hashes Some of these things inter-relate and so please look at the PRs at the same time.