IETF 104 IPsecME WG meeting in Prague Thursday, March 28, 2019 10:50-12:20 Karlin 1/2 Agenda: - Agenda bashing, Logistics -- Chairs (5 min) - Draft status -- Chairs (10 min) - draft-ietf-ipsecme-split-dns - draft-ietf-ipsecme-qr-ikev2 - draft-ietf-ipsecme-implicit-iv - draft-ietf-ipsecme-ipv6-ipv4-codes - Work items - Intermediate Exchange in the IKEv2 Protocol - Valery Smyslov (10 min) - draft-smyslov-ipsecme-ikev2-aux-02 - Post-quantum Key Exchanges in IKEv2 - Valery Smyslov (10 min) - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 - An implementor's view on Hybrid PQKE in IKEv2 - Tobias Heider (10 min) - PQC for IKEv2 in strongSwan - Leonie Bruckert (5 min) - ESP Header Compression and Diet-ESP - Tobias Guggemos (10 min) - draft-mglt-ipsecme-diet-esp-07 - Labeled IPsec - Paul Wouters (10 min) - draft-ietf-ipsecme-labeled-ipsec - IKEv1 Graveyard - Paul Wouters (5 min) - draft-pwouters-ikev1-ipsec-graveyard - Other presentations - IP Traffic Flow Security - Christian Hopps (15 min) - draft-hopps-ipsecme-iptfs-00 Agenda bashing, Logistics ========================= Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-chair-slides-04 (no agenda bashing) Draft status ============ draft-ietf-ipsecme-qr-ikev2 has a nit. Waiting for resolution to proceed Valery: Nit is a false positive; will make it go away very soon. Draft-ietf-ipsecme-ipv6-ipv4-codes ================================== Tero talked about draft-ietf-ipsecme-ipv6-ipv4-codes The room was polled about the alternate designs. Valery: Use status notification states rather than error. Prefers Tero's design (over his own) Tero: All of these are status notifications not errors. Tero: Not enought people commenting here. Both are acceptable. Will take to the list. Intermediate Exchange in the IKEv2 Protocol =========================================== Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux-02 Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-intermediate-exchange-in-the-ikev2-00 Paul Wouters: Update 7296? Because it changes the msgid of IKE_AUTH Valery: Will check PW: Silly to send an empty intermediate. Need to know what to ef Valery: An accompanying document will define what it goes there. Always need a new one. PW: rename to IKE_INTERMEDIATE, since this applies to IKE only Valery: don't mind. Tommy: Seems fine with msgid. RFC 7296 doesn't require it to be 1 for IKE_AUTH Tobias Heider: The draft already says that INTERMEDIATE can not be used without another document that specifies what payloads are sent in INTERMEDIATE. Why can't that additional document also define it's own exchange ID for that instance of INTERMEDIATE instead of using the same ID for different things. Valery: This is just a framework document Tero: It's OK to say this is just a framework. The documents that actually use it will define what goes in it. Tobias Guggemos: You can do PQ in IKE_INIT if you don't need IKE fragmentation. Tero: Too early for hum. Are we only going to ever have one? Tero: Any objection for adoption? (crickets) Tero: So will push the button and make this a WG draft (already asked on the list) Post-quantum Key Exchanges in IKEv2 =================================== Valery Smyslov - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-post-quantum-key-exchanges-in-ikev2-00 Surprisingly, a document using INTERMEDIATE IKE_INTERMEDIATE. What are the odds? Tero: I would hate to see this happening: 7 key exchanges sharing the same type 4. These are complete key exchange - not the same thing as DH. Need a new registry - they'll probably have their own parameters. Valery: They do the same thing as D-H: negotiate a key. Scott: Specifically we wanted to allow doing this group, then this other, then an isogeny group. This construct allows this to be done relatively straightforward. Tobias Heider: Like the idea of combining old (DH, ECDH) and new stuff Martin Fadman: Why the limit 7? Valery: Arbitrary Martin: Maybe this argues for the hierarchical idea. Valery: Scott things that in most cases different types will be used. We have three types, so let's double it Tero: Why negotiate all of this in the first SA payload? Interacts badly with parameters. Maybe negotiate them one-by-one along the way? Valery: What you are proposing will complicate things. Better to negotiate in advance what is going to follow. Maybe the responder doesn't support what you are going to require in the third round Mark ???: Having them all in one place is better Scott: About parameters: transforms can have attributes. Regarding the size of the SA proposal: not a problem with the encoding of IKEv2 proposals, at least for sane policies Tero: will continue on the list (as we're running out of time) Yoav: This is just for CCSA with PFS? We can still do CCSA without PFS Valery: Yes, and for rekeying of IKE SA Mark: Support adoption Tobias Heider: adopt, and rename to hybrid key exchange. Because it can be used with multiple classic D-H. Yoav: if we're adopting this should adopt also intermediate, and no point in adopting intermediate if we're not adopting this. Daniel Migault: Adopt, then make changes An implementor's view on Hybrid PQKE in IKEv2 ============================================= Tobias Heider Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-an-implementors-view-on-hybrid-pqke-00 Still controversy about breaking the PQ exhcnages out. Also with how to accomodate McEliece (large keys) Yoav: Can define a new "extended-size" payload to accomodate >64K key exchanges. PQC for IKEv2 in strongSwan =========================== Leonie Bruckert Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-pqc-for-ikev2-in-strongswan-00 Tobias Guggemos: We have 4 implementations. Maybe do a Hackathon? Tero: You going to organize this? Thanks! Tobias: Yes, if you fly me to Montreal Dave: Will take to the list ESP Header Compression and Diet-ESP =================================== Tobias Guggemos - draft-mglt-ipsecme-diet-esp-07 Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-esp-header-compression-and-diet-esp-00 (discussion on adoption will be done on the list) Labeled IPsec ============= Paul Wouters - draft-ietf-ipsecme-labeled-ipsec Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-labeled-ipsec-00 (already a WG draft. Discussion on Paul's proposed changed in selecting TS types will be done on the list) IKEv1 Graveyard =============== Paul Wouters - draft-pwouters-ikev1-ipsec-graveyard Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-ikev1-graveyard-00 Tero: We don't instruct people what to use. We can't tell people what to use. Dan Harkins: IKEv1 is already obsoleted. What more do we need? PW: We want to tell people not to use it. Smyslov: Support deprecating IKEv1 Benedict: Cannot get rid of 3DES. Used in telephony. PW: Yes, for now, but it's time for CAST IP Traffic Flow Security ======================== Christian Hopps - draft-hopps-ipsecme-iptfs-00 Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-ip-traffic-flow-security-00 Valery: Interesting proposal. You fragment IP packets to arbitrary size and then re-assemble. This complicates IPsec implementation. I'd rather sacrifice some performance (efficiency?) by allowing combining but not fragmenting. Christian: Let's discuss on the list Paul Wouters: Privacy and compressing are different goals. Why do we need the extra things. Christian: the 20,000% overhead. Lou Berger: The present thing is not deployable. We're destroying the available bandwidth with the trimodal distribution of packets. -- discussion to continue on list