Transport Layer Security (TLS) Working Group Minutes Meeting : IETF75, July 31, 2009 Location: Stockholm, Sweden, Room 307, 1300-1400 Chairs : Joseph Salowey , Eric Rescorla Minutes : Wes Hardaker, Jeff Hodges Version 2 ============================================================== Agenda 1. Administrivia - Blue sheets, note takers, etc (5 min) 2. TLS Cached Info (Santesson - 15) http://tools.ietf.org/html/draft-ietf-tls-cached-info-01 3. DTLS Heartbeat (Tuexen - 15) http://www.ietf.org/internet-drafts/draft-seggelmann-tls-dtls-heartbeat-00.txt 4. TLS - IBE (Huang - 15) http://www.ietf.org/internet-drafts/draft-huang-tls-ibe-00.txt 5. XMPP TLS Multiplexing (Hildebrand - 10) http://tools.ietf.org/html/draft-hildebrand-xmpp-tls-multiplexing-00 ========================================================== Meeting Report 1. Administrivia Joe Salowey (chair): Topic 5 on published agenda will not be discussed unless we have time as the authors are working on a different approach Tim Polk (AD): asked for time to discuss TLS authorization 2. TLS Cached Info - Presented by Stefan Santesson Draft: http://tools.ietf.org/html/draft-ietf-tls-cached-info-01 Yngve Pettersen: Was wondering about multiple hashes. Can we negotiate the hashes to support. IE, the server can list the hashes they support on the first connection so that the client can pick a hash-storage for their own side. Stefan (Presenter): I can't see it solves an important problem Simon Josefsson: With regard to hash collisions: there was discussion on the list but maybe we can repeat some of it now. there was no chance for complexity, but there is implementation complexity. To implement it I have to decide if it's hash data or not. I suggest putting in implementation notes Stefan: if you use the hash as a key then it can be a quick map into the data you already have. Simon: I'm happy to add that clarification Eric Rescorla (Chair on Jabber): now that I see this problem suggested, this seems pretty gross from an implementation perspective. I think I'd prefer that the cache hits be returned explicitly in the extension. I can send text. Teddy Huduborn: Is this only for X.509 methods, or will this help with other methods like PGP keys. Stefan: There is an open method for defining things that can be cached, and right now there is 2: certificate chains and (?). I'm open to defining others, are there others that we think might be useful? Put a suggestion on the TLS list if you think 3. DTLS Heartbeat - Presented by Michael Tuexen Draft: http://www.ietf.org/internet-drafts/draft-seggelmann-tls-dtls-heartbeat-00.txt Pasi Eronen (AD): I can see this being useful in cases, but I can also see it being solved in the lower layer protocols. For example, in IPFIX I can very much see them solving it at their layer. Michael Tuexen: I see your point but... Pasi: I can also see this useful for PMTU discovery. Michael: That's true but it doesn't necessarily work for bi-directional differences. You can send another message which contains extra stuff for doing discovery. SCTP has opaque data for doing things like that. I like the discovery message, but I think it should be another message. Eric (Jabber): this is relevant in TCP cases as well. Question: if you use this in UDP, the draft says you must not send them while you're waiting for a response. Michael: Only one heart-beat request in flight at a time. I don't want to have a congestion control problem Wes Hardaker: agree with EKR that it is useful it TCP as well, though you need to document differences. Longer discussion on the rational behind it. 4, IBE for TLS - presented by Min Huang Draft: http://www.ietf.org/internet-drafts/draft-huang-tls-ibe-00.txt Eric (Jabber): I already sent a fairly extensive review of this to the list. The basic problem is that this doesn't buy you anything. In particular, if you go back to slide 3, which lists the benefits: (1) It's not clear why having another alternative adds value. (2) It's true that there's no *certificate management* but there's still key management with the PKG, which is just as inconvenient. (3) The performance of IBE is actually quite a bit worse than EC. The EC operation is comparable, but the pairing is much slower. Further, when you actually examine the proposed mechanisms (in slides 7 and 8), neither of them seems practical. In the first, you need to ship over some ridiculous number of PKGs in the open internet context. In the second, it's not clear how revocation actually works. BTW, as far as I know, in deployed IBE systems, you generally give people both an IBE key pair and an X.509 certificate for compatibility with ordinary PKI, so the identity based auth system is unnecessary Richard Graveman: A lot of the previous comments are true. It is slower but the speed of crypto and today’s processors we just have to get over it. It seems that there are some advantages to using this within closed enterprises, but I'm not sure that's true for TLS servers within the global internet. I'd be strongly behind picking up on this on at least the experimental track (the draft says informational, but it'd should be). I don't know about proposed, but it's exactly the type of thing that should be on the experimental track. Eric (Jabber): Have you filed an IPR statement on this draft? Dave Harrington: I'm from the same company and our legal department is working on determining if we need to do that. Richard Graveman: There is GPL code available from Stanford to do that. Eric: disclosure is necessary. There are existing disclosures from BF and BE. Dave Harrington: if we have any IPR on this we will be filing them according to the note well policy. Joe: who thinks this is a good set of cyber-suites to add to TLS - 2 Joe: how many thinks this is something we should not do? - 6 5. XMPP TLS Multiplexing - skipped 6. TLS Authorization Tim Polk: 92 days ago I put a mark in the tracker I put a marker on the list about doing a standards track document about Russ' authz draft. I haven't seen any information about whether the TLS WG was going to take on work in the area. But I haven't gotten any notices, so I'm assuming the WG isn't going to do anything about the subject. So in a week, after I get back, I'll let it be published as experimental. 7. Open Mike Yngve Pettersen: 2 weeks ago I sent an email about the cert status extension. It's currently only handling the status for a site certificate. A number of CAs have been issuing intermediate certs with our extension. Only a few CRLs exist. A number of years down the road I expect more CAs to be needing to revoke certificates. What this probably needed is a new message or a new message format about certificate status. There is a lot of clients going to the CRL server and its already causing a lot of load issues and the usage is still small. We had a case where Joe: so having the server doing the request and caching the response is a benefit Stefan: Thinks this is a good idea Joe: I think it would better to do this as a separate document that updated the other, because it would be another extension right? Yngve: It would need a new type otherwise a new message would be needed. Joe: a proposal of what the extension would look like would help. Yngve: I don't have that at the moment, but I hope to.