IPsecME @ IETF 95 April 4, 2016 1400 - 1530 Minutes taken by Adam Montville and Yaron Sheffer Summary: - Didn't meet in Yokohama (IETF 94) - WGLC issued on draft-ietf-ipsecme-ddos-protection. Wrapping up changes based on feedback before sending to IESG. May need to consider splitting puzzles out as an experimental draft. - WGLC on draft-ietf-ipsecme-rfc4307bis and draft-ietf-ipsecme-safecurves to be issued soon. - New work to consider. Some interest in the WG on the following, but more feedback is needed on the list over the ideas/drafts: draft-mglt-ipsecme-rfc7321bis-00 draft-ietf-ipsecme-safecurves draft-pauly-ipsecme-tcp-encaps - Need to recharter, more discussion on specifics on the list to follow. Raw notes: From Adam Montville: IETF 95 - IPSECME NOTES 14:00-15:30, Quebracho A Agenda as Posted 5 minutes: agenda 15 minutes: discussion of conclusion of WGLC on draft-ietf-ipsecme-ddos-protection 5 minutes: request for more comments on WGLC on draft-ietf-ipsecme-rfc4307bis 5 minutes: draft-ietf-ipsecme-safecurves 15 minutes: draft-fluhrer-qr-ikev2 15 minutes: draft-pauly-ipsecme-tcp-encaps 10 minutes: draft-smyslov-ipsecme-ikev2-compression 10 minutes: changing the requirements for registry entries Rest: charter About 25-30 folks in the room and seven folks in MeetEcho (no clue on overlap). Chairs are starting the meeting. Full agenda is planned, so we'll stick to it closely. Note Well is being displayed (the new one?) We have two note takers and one jabber scribe (Jim Schaad) Status report: https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-1.pdf Didn't meet in Yokohama, but a lot of work has been done over the last few months. Good progress overall Three "active" drafts. DDOS has been getting a lot of traffic 4307bis will be issued soon - seems verified by authors in the room safecurves is ready soon for WGLC Likely to add draft-fluhrer-qr-ikev2 We need to recharter, which happens from time to time Agenda bashing: None. Sheila Frankel: Not really agenda bashing, but... Do most implementations cover elliptic curve? Do some implementations have known ESP? Chairs: Why don't you send these questions to the list to get your answers... Paul Wouters: There's another draft we might consider: Update to ESP algorithms. Chairs: Agree, we should get some feedback on the list. DDOS Protection (Valery Smyslov) presentation: https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-2.pdf Sailing through the presentation with little to no engagement so far from the folks in the room. No questions. Dave w.: There seems to be good progress on this...do you have enough feedback to address Paul's concerns? Paul W.: One issue is whether or not puzzles will work as we expect. I am not convinced that puzzles will work. Yoav Nir: In the past my company has implemented puzzles similar to this and this worked. What we're missing now are measurements about how fast ARM processors are to solve these puzzles. There's some disagreement about whether puzzles are suitable for preventing attacks. I'm not sure I can say how many attacks were stopped. Tommy Pauly: To the point of getting numbers on this, we can implement it on both and see how it works out. I should think that the mobile devices would be comparable. Tero Kivinen: I think the puzzles are mostly for the future. WE haven't seen attacks against this yet, and if you have a mechanism already defined, then you can try to protect...I don't know if puzzles will be implemented early on, but if they're there we're ready. Valery S.: The hope is that puzzles will help. We also believe that puzzles will help in certain circumstances, and it's better to have them in place. Jim Schaad for Kathleen M.: This draft is standards track, so maybe the viability of including puzzles is something that suggests this should be experimental. Paul H.: This sounds like a good discussion for last call. RFC4307bis presentation (Tero Kivinen): https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-6.pdf Paul W.: We left it at 128-bit keys and I would like list discussion to determine whether we bump this to 256. Is there any reason to stick to 128? Dave W.: Start a thread. Paul W: Once you start switching the default, you run into invalid KE, so it's not supported anymore. This is the most risky change (context: IKEv2 Diffie-Hellman Groups) Paul H: Document has a fair amount of discussion on this topic. Yaron Sheffer: Should this and the other draft be aligned and published together? Paul H: That can be discussed, but the other draft hasn't even been picked up yet. Daniel Migault: If you don't understand some text, it's important that you mention it. Safe Curves (Yoav Nir): https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-0.pdf Yoav N.: He's asking whether we want to wait or move forward for signatures Paul W.: I thought the whole point was that we would let other working groups take care of this? Paul H.: We can wait for the curdle work, which is happening later. It looks like no one objected to this working going to WGLC. Quantum resistance (David McGrew): https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-7.pdf Going through the deck with very little feedback so far. Valery S: i think this draft is important. My idea was not to introduce a new register, but to ... [missed that]...this will give more simplicity David M.: When we wrote the draft, we recognized that IO registries aren't expensive. Dan Harkins: IKEv1 to get around the problem and using extensions that contain multiple named keys, so what you can do is connect this to two message exchanges... Give out the PPK and some sort of hint key and this could be smaller and shorter and key-wrap a name, which would be an index into thousands of PPKs. Why go through the crypto algorithms? To make it probabilistic, you could do something like XXXX mode and ensure that your wrapped data is going to be unique every time. David M.: Have you looked at this from quantum perspective? Dan H.: Probably not. (Laughter) David M.: One of our security goals was to preserve integrity in the face of quantum computing. Let's talk more offline. Tero Kivinen: I think that quantum risk is really important for IPSEC but not as critical for IKE. Traffic selectors...most of these are visible already, so it doesn't gain much to hide IKE elements. We might end up with the same problem for IKEv2 that we have with IKEv1. From an implementation perspective, we might be putting ourselves in a position where people will in effect reuse PPK. [He offered something interesting here, but I missed it - sorry.] If someone mistypes PPKs at either end...we need to verify these things. David M.: It is possible to choose computed values. It is possible to configure a system to make a choice toward performance; the idea being that it's up to the user to make that choice. They're having a good discussion on this, but Paul had to cut it short. Valery S.: Quantum security key... PPK key as a current draft protects us today, and you can use algorithms that resist quantum today. Paul is encouraging that we do this later. TCP Encapsulation (Tommy Pauly): https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-3.pdf Yoav N.: If you don't want an arms race with firewalls, ... I don't get why you would want the TLS. Tommy: I have some slides on this later, and we can take the arms race so far but not further. Maybe we're going to do something that would make it look how it should be. Paul W.: If you go to Starbucks around the corner, you can't do anything but 443. The arms race is here. WE might as well explicitly state that we support customized ports. Tommy: We should take extraordinary measures to mask... Brandon Williams: Any idea of goals vs. non-goals for proxy/transparent proxies? Tommy: Draft briefly mentions proxies. I'd like to have a small as explanation of that in this draft. If it changes IKE, then it should be in this draft, otherwise a second draft. Brandon W.: Might be worth second discussion: When TLS is being used flag it as {missed}HTTP, so the proxy won't terminate the session. Tero K.: 3GPP talks about a couple of formats. Should we try to align with them? Tommy: Can you send that to the list? Tero K.: Yes. Valery S.: This is difficult to make cleanly. To deal with FWs and proxies will be ugly. A document to describe how to get around these things seems to be the right approach Tommy: Practically, we want to in this draft ensure people don't fall into pitfalls Paul W. is asking whether running a call for adoption? Paul H. is suggesting that there is some discussion that needs to be happen. We'll have the discussion about this document and what pieces of it we should adopt or not. Daniel Migault: When are we going to have this discussion? Paul H.: As soon as [something] happens, we'll have the discussion. Essentially, we want to scope the draft before we adopt it. IKEv2 Compression (Valery S.): https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-4.pdf Paul W.: For the SA if it's large size, compression is good, but how does this fit with IoT which won't be very good? IoT tend not to use certificates, so the things this does well are the things that IoT doesn't do. Valery S.: I don't think it's completely useless for IoT Tero K.: I agree [with Paul]. I don't think IoT devices benefit from this. Tommy: It seems that everything outside IKE we should fragment if we absolutely need to send it. Is this really just about trying to reduce energy? Valery S.: Why send larger messages if you can send smaller ones? Dave W.: It would be good to explore some of this on the list. Chairs had to cut it short for the next presentation and we have only 15 minutes left. IPsecME IANA Issues (Tero K.): https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-5.pdf Daniel Migault: Would it be valuable to have a BCP? Tero K.: It depends on case by case. Daniel M.: So the message is definitely "come to the IETF before doing anything" Paul W.: The biggest thing from telco world is that they can't wait for the slowness that is IETF. Can we convince them that we'd be faster? Paul H.: We can handle this response without going through draft process, but rely on e-mail. Paul W.: But, I don't think we should leave that process in place. I would just want to read an RFC. I would like it to be mandatory to go through our group. Tero K.: As an IANA expert I can make sure that all happens. John Matteson: [Missed this one.] Paul W.: Maybe just them submitting an I-D would help? Tero K.: This is not impossible to handle in e-mail only. Paul H.: If you (Paul W.) don't like what Tero just said, do a draft that describes what you'd prefer. Charter Discussion (chairs): https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-1.pdf Paul reminds that WGs adopt ideas not documents. It seems that quantum resistance and TCP encapsulation are well-received ideas, but the documents are not necessarily fully well-received. Tommy: If there are any problems with specific contents in TCP encapsulation, it can be changed. Third topic is the ESP doc might also have interest. Paul H would like to have last call for 4307bis and also do ESP. Paul W.: There have been some people with interest, but this was with an older draft. Ok, then let's rev that draft and have discussion. Daniel M.: When we recharter and can we update when the topic isn't part of the original charter? One suggestion was to make the charter more open than previously arranged. Paul H., I'm hesitant to leave charters too open, and I prefer to make them strong and specific. Chairs have more work. Paul W.: Isn't this the IPsec "ME" working group? Paul H.: The AD would like the group to come together and not do everything but what is agreed upon that must be done. We still have plenty going on, but we have another set of things starting. It seems like there's enough interest in the work that is being done. But, please don't take this as a call to not finish what won't be done. Don't worry about sliding everything into the charter now -- it's better to accept a later I-D and update the charter. From Yaron Sheffer: PH: 4307bis: will or will not publish a new minor version, but will go to WGLC soon. Sheila Frankel: do most implementations currently have EC in them? Implementations of null-ESP? Will send a question to the list. Paul W.: we might want to discuss the draft on ESP algorithms. Puzzles Valery: remaining issues are clarifications requested by Paul W. Paul: still unconvinced about puzzles in general, specifically for low-power clients. Yoav: testing on some clients. He had the feature in a product version but cannot say how much it helped. Tommy: some algorithms are actually better on ARM, so mobile devices may be more comparable than we think. Tero: puzzles are mostly for future use. We haven't seen attacks yet where puzzles would be useful. No other protocol has a similar feature. Kathleen: it would be better to put this doc on the Experimental track until we have harder data. PH: something we can decide at the end of LC, or maybe reopen the discussion of splitting the doc. RFC4307bis Paul W.: would like list discussion whether we should move from 128-bit keys to 256-bit. Paul W: the changes to DH groups might actually kill some clients, this is risky. But still agrees with the changes. PH: not clear now if 4307bis is ready for WGLC, maybe needs to be tied to the new IPsec algorithms draft. Daniel: please also send us textual/editorial comments. Safe Curves PW: prefers to use OIDs instead of making digital signature decisions in this WG. PH: we will do WGLC on this draft soon. Quantum Resistance Valery: let's not use a new algorithm registry. Dan H: the hint could be an index wrapped in a key, where this is an index into large table of PPKs. Use AAD (?) Dave McGrew: not sure how this would provide identity protection in this setting. Tero: we need QR for IPsec but not really for IKE. The attacker in reality does know my identity from other information. The problem with the proposal is that if anything goes wrong, the recipient doesn't know who the client is. Or we might end up with huge tables of PPKs. Proposes to get rid of this mechanism and live with with the active attacker seeing identity. DM: you can have precomputed values to avoid the linear scan. Tero: this is actually a DOS attack waiting to happen. Should also allow one-time pad use for PPK. TCP Encapsulation Complexity and differing opinion about where we want to be in the arms race with firewalls and captive portals. Brandon Williams: what about proxies? Tommy: this belongs to a second draft, on how to use this encapsulation in different use cases. Tero: the 3GPP doc does specify the format, but with a different length for the length field. Will send the ref to the list. [Sent] Valery: TLS in this drafts looks like a hack, cheating. Better to have it as a separate draft. Tommy: people will be doing it in TLS, we need to stop them from doing stupid stuff. PH: still not ready for adoption. We can have the adoption discussion as soon as the new version comes out, addressing Valery's comments. IKEv2 Compression Tero: compression more expensive than encryption, will not be usable for IOT. Valery: compares sending 1 bit of info on the network to running 700 instructions, so this does make sense for IOT. Tommy: is it mostly about saving energy? DW: we need to further explore the motivation on the list. IANA Considerations Daniel: maybe we should publish a BCP to preempt some of that? Tero is skeptical. Daniel: the message is for consumers to come to the IETF early. PW: complaints from telcos at ICANN. Can we commit to an SLA? PH: they don't need to go through a process. Just send us email. PW: we should mandate for them to go through the WG. Tero: some trivial stuff can go only through the Expert. PW: maybe make them submit an I-D? PH: suggest that Paul W write something up to open this discussion. PH: the group will probably meet in Berlin, and might even adopt new work into the charter in between.