Transport Layer Security (TLS) Minutes Meeting : IETF76, THURSDAY, November 12, 2009, 1510-1610 Location: Hiroshima, Cattleya East Chairs : Joseph Salowey (jsalowey@cisco.com), Eric Rescorla (ekr@rtfm.com) Scribe : Sean Turner (turners@ieca.com) Version : 0.5 ============================================================== A. Administrivia B. TLS Cached Data C. Additional PRF Input D. TLS Renegotiation Vulnerability ==================================================== A. Administrivia Scribe: Sean Turner Jabber: Multiple People on Jabber Webex: Attendees on Webex Agenda modified to make for room for renegotiation discussion. Additional topics moved to the end. B. TLS Cached Info draft-ietf-tls-cached-info-02 (Stefan Santesson) Stefan presented slides on draft-ietf-tls-cache-info-02.txt. He presented a short (debatable) recap of the approach. He also presented that status that there were two suggestions at the last IETF, but no input is provided. Stefan asks for WG LC. Joe indicated that the WG LC would occur as soon as the renegotiation issue is properly addressed to make sure all eyes were focused on the renegotiation solution. Action: Chairs to start WGLC after renegotiation is far enough along. C. Additional PRF Input draft-solinas-tls-additional-prf-input-01 (Paul Hoffman) Paul Hoffman present an individual ID: draft-solinas-tls-additional-prf-input. He presented the motivation for the ID: some people want to add data to the master secret calculation with one generic way. He also discussed the proposed mechanism and two IANA registered types (additional random and OtherInfo from NIST). Status a) Simon pointed out there was no structure so it got added b) Pasi Eronen also pointed out that the mechanism also people to subvert the normal IANA registration process for TLS extensions c) no other issues. The next version is going to address Pasi's concerns. After the -02 version, Paul may or may not ask for WG adoption. Eric Rescorla (webex): noted that he sent comments on the OtherInfo. The way the OtherInfo didn't pick what the structure was so there's no way to get interop. Paul: will pick one of the structures Eric: pointed out that this really wasn't his point. Nico Williams: proposed that it is best done by adding the addition input to the final message contents. Also, if you do this as a hello operation then it's easier to implement. Paul: was not doing it for channel bindings, but Nico was thinking that it might be useful. D. TLS Renegotiation Vulnerability draft-rescorla-tls-renegotiation-00 (Joe Salowey) Joe Salowey presented the TLS renegotiation vulnerability. He presented an overview of TLS renegotiation: a TLS handshake occurs under the existing TLS handshake and the new one takes over for the old one. He then presented the renegotiation attack: applications don't know where the renegotiation occurred. He also presented the vulnerability: a) attacker can inject data that gets processed under the client content b) attacker sets up context that discloses information in client' requests. Because TLS is used for just about everything, other protocols may be vulnerable including IMAP, LDAP, XMPP, SIP, SMTP, and on and on. David (webex): the various attack pretends data? There's another attack where the attacker can hijack the session after the renegotiation. Eric: isn't clear how this can occur. Joe: says move on and let's find a solution. Joe S. proceeded to discuss the possible mitigations a) disable renegotiation (not really practical) b) a new extension (preferred approach by Eric R.) c) application mitigation (very application dependent). Joe S. explained option b) is a hello extension containing the content of the finished messages from the previous handshake. This approach doesn't solve world hunger but it does fix the MITM attacks. Pasi Eronen:There are some open issues but all of them are essentially procedural and this seems like the way forward. Yaron Sheffer: His understanding that both client and server need to implement; therefore, it's a long term solution; is there a short-term solution. Eric: there's nothing the client can do to mitigate. David: are we breaking servers that rely on this? Eric: It seems unlikely. Joe S. proposed a timeline that starts now with a WGLC next week and ends on Valentine's Day '10. Chris Newman (jabber): Add "updates" header and say don't do what's in the old RFC. Pasi: We are going to get a new extension type. Chris: Can we do both WG LC and IETF LC at the same time? Russ/Pasi: Let's do AD review and WG LC at the same time. Most in the room feel we can move the date up. Sam Hartman: We could issue and extension and burn a code point because we've got a 16 bit name space (i.e., we could burn some). Pasi: We want to have one solution. Eric: It's not that we're burning extension #s, we'd be sending three different extensions because we don't know what the server supports. Pasi: A date for formally giving out an extension # is Dec 3rd. Tim Polk: We have two opportunities tomorrow and next Thursday. He just wants then to delegate it to Pasi. Chris (and others): Wants IETF LC and WG LC to be done at the same time. Russ Housley: Are there implementers that can give us a real date when they need it (i.e., not too early). (Jabber): It's already in OpenSSL. NSS says tomorrow would be good. Joe S. indicated that there might be some follow-on work such as API considerations and applicaiton integration considerations.