Hi Tero, Thank you for sharing the minutes.
Please see inline a comment to Valery. Cheers, Med > -----Message d'origine----- > De : IPsec [mailto:[email protected]] De la part de Tero Kivinen > Envoyé : jeudi 28 mars 2019 17:18 > À : [email protected] > Objet : [IPsec] Preliminary minutes for the IPsecME meeting > > Here is the preliminary minutes for the todays IPsecME meeting. Thank > you for Yoav for taking the notes, and Paul for jabber scribing. > > If you have any comments, corrections or additions to minutes, post > them as soon as possible. I will submit these to the meeting materials > early next week. > ---------------------------------------------------------------------- > 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. [Med] The draft does not use error types but notification status types. Prefers > Tero's design (over his own) > 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: ?? > 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 > -- > [email protected] > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
