Security Dispatch (Secdispatch) WG Minutes IETF 105 Monday 2019-07-22 Location: Place du Canada Summary ======= The following items were brought to the WG meeting and were dispatched as follows: (1) draft-richardson-lamps-rfc7030est-clarify-02 -- Dispatched to LAMPS (2) draft-carrel-ipsecme-controller-ike-01 -- Further discussion is needed, especially to clarify the use cases (3) draft-hallambaker-mesh-architecture -- Further discussion is needed. Raw notes from Bret Jordan follow. ===== Security Dispatch WG Meeting IETF 105 - Montreal - Monday 2019-07-22 Location: Place du Canada Chairs Present Kathleen Moriarty Richard Barnes ADs Present Benjamin Kaduk Roman Danyliw 13:34 - Start Meeting • Logistics and introduction (chairs, 10 min) Kathleen started the meeting 1st session will not follow normal format No agenda bashing (a) EST update (4 minutes present, 4 minutes discussion) draft: draft-richardson-lamps-rfc7030est-clarify-02 presenter: Michael Richardson Michael Richardson - RFC7530 extension, talked about Enrollment over Secure Transport. About certificate enrollment. No one is using the content extension header since it is deprecated by all the HTTP specifications. No implementations in the wild. Two of the issues raised by Sean Turner. A simple clarification document. Transfer content-transfer-encoding is broken and this document talks about how to deal with it. Moving to binary is not a good option since individuals like to use curl, so base64 is a better option. Trying to figure out where to send the document. It needs an ASN.1 review Martin Thomson - preference to send to existing working group. Sean Turner - send to LAMPS. We should fix this thing. We could use the HTTP accept header to try and tell the end devices what they accept. Michael, this does not work for the POST Roman - Need a charter to send to lamps ? - Send to lamps Martin Thomson - Talk about POST, Russ - pass the blues sheet Decision from chairs: Dispatch to LAMPS (b) Controller-IKE draft: https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01 Also some docs referencing this form of key management: BESS, Secure EVPN: https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-02 And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-01 presenter: David Carrel David Carrel IKE is basically a Key management protocol that will work with a controller. A diffi hellman exchange. Keep the scaling of the messaging down. The problem they had is with large networks, 10,000 nodes in a mesh, there was too much traffic. Potential issues, is with rekeying and synchronization. The draft addresses the synchronization problem with a centralized controller. This is not a replacement for IKE. It is not a 2-way attribution negotiation protocol. In this model we are coming from a centralized controller. Not worried about negotiating desperate attributes. We are not providing the secure communication channel. This is meant to be in some other communications protocol. Why. Optimization, reduced complexity and reduce messages from n^2 to n. Orgs want to have more control over managed networks. Some links are not bi-directional, but they can still talk to the controller. Other areas where this is being discussed, I2NSF, BESS, IDR, RTGWG, etc. There are two implementations of this draft. The two drafts are highly related. A lot of working groups are trying to integrate a controller based design. EKR - question about what is counted in the n^2 versus n. David - messages. EKR - with this design you are not getting PFS. An alternative design would be… ???? David - This is not the be all, in all, controller model. EKR - You do not want to do Peer 2 Peer, so what are you trying to save? Michael Richardson - is this for split brain controller???? Overall concerns about not using Peer to Peer ???? - discussion about signaling. Linda?? - Strongly support this proposal. When enterprises talking to cloud or multiple clouds, there is lots of connections. Without this, the network is not scalable. ???? - I2NSF has a similar solution, an IKE-less. David - The I2NSF solution requires that the controller knows all of the keys. Which is obviously a limitation. David - The architectural model put forth in BESS EKR - Not sure about the use cases and how it differs from other solutions ??? - This assumes your whole network is static. Does not think every node in the network needs to talk to every node. David - this work works really well in dynamic networks. Phil - This is not so much a key exchange but a message flow. I am interested in this, and this is why. This looks very close to kerberos. This could be viewed as a fail safe for quantum resistance. ??? - Performance improvements. He would like to see data. Like to see performance gains. Alex - When you add a node, it talks to a central router….. low power, low end nodes, do not have the capability of sending… public keys Danny - Some people say there are better way of doing this. < missed a person > ???? - The controller has to dictate Ben - Need more clarity for people in the room, is this an overlay network, people in the room need more information. Decision: Make requirements more clear. It can stay in SecDispatch. Nothing for now, revise and define requirements more clearly. (c) Mathematical Mesh draft: http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html The following drafts are nearing completion: http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html http://mathmesh.com/Docume…/draft-hallambaker-mesh-dare.html http://mathmesh.com/Docu…/draft-hallambaker-mesh-schema.html http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html presenter: Phil Hallam-Baker Phil Internet security is broken. Most of the breaches are on data at rest, but we focus on transport. Need more separation of duties. Need more keys. The Mesh is a platform. People are not going to use PGP for email if they can not read their email on every devices. We are still using the stuff from the blue book not the red book. It is a platform. Multi key platform. UDF uniform data format. We could add this encryption key to a domain. This has multiple uses. QR Code. All data in the cloud is encrypted. Even if the cloud is breached, the cloud data is safe. You can now do block chain like integrity or Merkel trees. Incremental Encryption. Applications. Mesh Account belong to a user to a service. You can use the same tech for logs to help get to GDPR compliance. This is almost a zero trust model. I do not want to trust any key put in by a manufactures. Some of this was developed in the 1990s, but it was not part of the PGP cannon so it did not get used. Designed to be end to end secure and abuse resistant. It does not prevent SPAM, but it makes it hard to make money with SPAM. This can expand multi factor. Where do we go from here. Is this ready for the IETF. If the IETF does not want it, then it will need to go some where else. Once I start accepting users, I will not want to make changes unless there is a real reason. ???? - Question on IPR. Phil - There is a bunch of prior art that would invalidate IPR claims. All of the code is MIT. Phil is not aware of any IPR issues. You can use the use the mesh to distribute keys for SMIME and PGP. You could use this with open pgp, you do not change encryption at all, just just decryption. Martin Thomson - Thanks for bringing this here. If the IETF takes this on, this is a major project. It will take some time to get going. How many other implementers do you have working on this. Phil - none. Phil - Do not wait until people adopt to read the drafts. EKR - We are not replacing SSH, Phil, this is not about replacing SSH. You can use the mesh to distribute the SSH keys. ???? - You say this can help with IoT world. Phil - the mesh network can help. You can avoid depending on cloud services. Sean Turner - This does not seem like a good fit for the IETF unless you are willing to make changes. Phil, I am open to changes. Rich - This seems like a large thing. Maybe if there was a smaller amount that we could pull parts of the work out to work on. ??? - Take to some other place to work on Bret - Thank you for doing this, I fully support this work. Roman - This is a big thing, we would need a BoF. Phil - Part of the requirements for doing a BoF is to make sure you have people aware of it, that is why I am here. Kathleen - We should setup a list Decision: Setup a mailing list and do a BoF 14:45 - End Meeting