Transport Layer Security (TLS) MINUTES Meeting: IETF84 Tuesday, July 31, 2012 Location: Vancouver, BC 1030-1130 Chairs: Joe Salowey jsalowey@cisco.com Eric Rescorla ekr@rtfm.com Minutes: Max Pritikin pritikin@cisco.com Version: 1 ========================================== 1. Note Well, Agenda, Note Takers, Blue sheets (1 Min) 2. Out-of-band public key validation (20 Min) - Wouters http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 4 people read the latest draft Eric Rescorla: can't violate tls extension semantics, so this needs to be fixed. since the only reason we changed to this was to get around down ref we should go back to the previous mechanism and copy text so this document can be on standards track. Asks if Area director is fine with copying text from RFC 6091. sean turner: fine with copying the text eric: put client ID in the key identifier Paul Wouters: we could do this, doesn't see any problem Joe: restated and found there is agreement. Joe: should take client ID to list. 3. Cached Info (10 Min) - Tschofenig http://tools.ietf.org/html/draft-ietf-tls-cached-info-12 Hannes: document ready for last call. Joe: OK we'll start last cal if there are no objections. No Objections. 4. Certificate Status Extension (2 Min) - Pettersen/Chairs http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-01 Joe: how many people have looked at the draft - 2 Joe: SCVP is new Sean: asked for it, but not sure it is the right thing. Joe: please review the draft 5. Version Rollback (15 min) - Pettersen/Rescorla/Langley http://tools.ietf.org/id/draft-pettersen-tls-version-rollback-removal-00.txt Presentation (by EKR): Improve security of rollback mechanisms. Servers have implementations flaws that keep this from working well (version fallback). Three proposals eke, langley, Pettersen. All make use of cipher suite signaling. Joe: Does the WG want to work on this? hum Don't work on this? silence (none) In the room Hum says: we should work on this. What approach seems best to start with cipher suite or RI? Slight Hum advantage to cipher-suite approach very inconclusive. People need more time to think about this. 6. Dragonfly/TLS-PWD update (2 Min) - Harkins http://tools.ietf.org/id/draft-harkins-tls-pwd-02.txt Dan Harkins presents. CFRG has presented Dragon Fly to the CFRG and had review on the CFRG list. CFRG asked for draft of just key exchange algorithm. Like to take draft standards track and get code points, also looking for interop. EKR: What doe the CFRG chairs think? Kevin Igoe: We approve of it, very clear and usable for general setting. EKR: are you working on other password authenticated key exchange mechs Kevin: No this is the only one in hand. EKR: Can you or david send this in a message to the TLS list? David Mcgrew: Tie Dragonfly into EST would be very useful. 7. TLS Proxy - Nir (10 Min) http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 Presentation (Nir): proxies exist that "attack" the TLS connection by inserting custom certs in the cert store that are used to sign proxy certificates for sites. The reason is to check the traffic for malicious content. Proposal makes proxy visible to the client and involves the client in the exchange. Hannes: in 2000 a "raven process"(?) document was published which conflicts with the proxy concepts presented in this draft. 2 options in enterprise: a) fake root cert to clients parental control software would work as well b) issue fake certificates (to server?) argues "lying" in the middle is bad should solve the problems w/ something at the end host Yoav Nir: not possible in Bring Your Own Device model Hannes: just have to provide more software Eric: client is still configured to trust the proxy. Proposal is to trust a specific proxy. Yoav: Browsers puts up a UI to accept trust in proxy Ekr: browsers not likely to support this. Ryan Sleevi: discussion: a UI popup is unlikely to be acceptable because it makes it so clear that traffic is being watched. Sean Turner: feedback on slide 11 conflicts with rfc 2804, "this would be a firefight" "this is horrible" "extremely challenging" stephen farrell: I agree Wes Hardaker: "who are we doing this for?" the solutions are being designed to allow more wiretapping and eavesdropping these extensions don't work for the cases i care the most about (which is somebody being there that shouldn't be) these solutions are helping the people i don't want to help "you are allowing the proxy to show themselves, but who is going to do this?" Hannes: half this document should be about privacy considerations ekr: historically proxies are enabled by OS changes but now browsers will need to be changed due to pinning Dan Wing: this doesn't help intercept or wiretap because browser still needs to be configured this is an improvement *because* of the configuration Ryan Sleevi: slide 8, if you're an enterprise operating a proxy then the client & proxy should have the same policy (these are not problems) Patrick Patterson: this helps make client certificate authentication work but a man-in-the-middle will fail so this will be disallowed anyway so this won't help. so this will be turned off in policy anyway; it won't be used Paul Wouters: this is why i'm publishing TLSA Records, to thwart man in the middle. Stephen Santessan: how does this effect channel binding mechanism? Yoav: still not addressed. channel binding info would have to be forwarded (dangerous) Joe: Sense is that there is not yet consensus nor support from leadership This is bigger than just changing TLS (would require charter update) David McGrew: agrees privacy considerations need to be added is there a need for ietf to indicate requirements in this area? Hannes: there are various documents about these cases and will post to the list Sean: 2804 and others suggests non-standards track approach dan wing: doesn't believe there is a document describing what happens today hannes: in transport area has a presentation about censorship academic work referenced will forward pointer to docs dan wing: current practices are not described hannes: agrees, we don't have such a document eric: we can find out what is done. should be easy to document current practice.