Transport Layer Security (TLS) Minutes Meeting : IETF77, THURSDAY, March 25, 2010. Location: Anaheim Hilton, Huntington room, 1510-1610 Chairs : Eric Rescorla , Joseph Salowey Minutes : Paul Hoffman ============================================================== Agenda 1. Blue Sheets, Note Takers, Agenda, status (5 Min) 2. Extension Definitions - Salowey (10 min) draft-ietf-tls-rfc4366-bis-06.txt 3. Cached Info - Santesson (15 min) draft-ietf-tls-cached-info-03.txt 4. TLS Heartbeat - Tuexen (10 min) draft-seggelmann-tls-dtls-heartbeat-01 5. Multiple OCSP - Pettersen (5 min) draft-pettersen-tls-ext-multiple-ocsp 6. TLS-PSK-EMV - Urien (10 min) draft-urien-tls-psk-emv-01.txt ============================================================== (Things on the slides are not duplicated here) 1. Status Exporters is now an RFC Renegotiation extension fix is now an RFC 2. Extension Definitions - Joe Salowey draft-ietf-tls-rfc4366-bis-06.txt Server Name extension Client can provide multiple names All clients only send only one name, and many servers ignore the rest - Pasi Eronen: not clear what the semantics of sending more than one is, easier to forbid the case - Ekr: Must only send one. If you see more than one, take the first one - Joe: agrees In session resumption, you ignore server name - Pasi: Add a few sentences that sessions are not scoped by server name - Russ Housley: Thought all extensions are ignored on resumption - Joe: All the ones in this document are ignored - Pasi: This is about server action - Ekr: Thinks this still OK, but you can segregate by server name if the server wants to. In renegotiation, server name can change If the client offers a new name, server must fail. SHA-1 without algorithm agility + Trusted_CA_Keys: Not important + client_certificate_URL: Possibly important - Stefan Santesson: This sounds like the discussion we had for cached info. - Joe: But this applies to existing extensions. - Yngve Petterson: There may be a delay between when an OCSP responder is updated - Russ Housley: This is no different than with CRLs - Pasi: "In PKI, there may be delays" is obvious. - Yngve will send text. Maybe can ship this off soon. 3. Cached Info - Stefan Santesson draft-ietf-tls-cached-info-03.txt Lots of discussion since last IETF Added hash algorithm agility. Also using FNV-1. - Ekr: why are we going this direction? We're going to have SHA-1 forever, let's just use it. - Stefan is fine with SHA-1 with no agility. 4. DTLS Heartbeat - Michael Tuexen draft-seggelmann-tls-dtls-heartbeat-01 Good for Path MTU discovery. - Ekr: You can send anything for the heartbeat? - Michael: Yes. - Ekr: What about merging with the Nokia folks? - Michael: We split that up, and I used some of it. - Ekr: Seems reasonable to take this on. - Joe: No negative response. - Wes Hardaker: Is referencing it from his draft. Will solve some problems for him. - Show of hands to review: Pasi, Wes, Joe, Ekr, Lothar Braun 5. Multiple OCSP - Yngve Pettersen (5 min) draft-pettersen-tls-ext-multiple-ocsp - Russ: Knows several OCSP responder who use the CRL NextUpdate, so this does not make sense - Yngve: Client might cache for longer Some OSCPs be issuing sub-CA with longer periods. This is for dealing with intermediate CAs's certs - Ekr: Wants to know if server operations will use this - Yngve: Google might add this - Stefan: Isn't HTTP caching taking care of the load? - Yngve: No - Sean Turner: Shouldn't this be handling SCVP? - Yngve: Can have multiple methods. New proposal on validity period for responses - Peter Andre: Isn't this going to increase the traffic? - Yngve: This depends on the number of users, not servers - Joe: This is more of a PKIX problem than a TLS problem - Joe: The earlier one seems major, wants to know if there is enough interest in the WG before taking it on. - Henery: If you shorten the validity time in one place, that might not get the security you want. - Sean: If you have a rogue server, you have more problems then that. 6. Presenter not available