Ipsecme Status PagesIP Security Maintenance and Extensions (Active WG)
Sec Area: Eric Rescorla, Kathleen Moriarty | 2008-Jul-08 —Chairs:
IETF-99 ipsecme minutes
Session 2017-07-21 1150-1320: Karlin I/II - Audio stream - ipsecme chatroom
Minutes of the IETF 99 IPsecME WG meeting Prague 2017-07-21. -- Paul Wouters on Split DNS Francis: presentation format means textual. Wire format is just as easy. Said as a DNS person. Tero: MUST be uncompressed. So it can be easier to parse. Paul: most apps are using presentation format. Wire format rarely used. We have no precedent for wire format, so could use presentation format. Tommy: could go with either one. Prefer presentation format. We already have strings and FQDNs (Tero: no, not strings). Tero: we only send one item, no formatting/structure around these strings. Tommy: not a list of items, no spaces. Multiple properties if multiple values. Tero: do you have escaping, backslashes? Paul: you still need to have security checks after conversion from wire format, because it is untrusted. Tero: agree. Wireshark can "decode as DNS". Paul: finds the security format minor. Tommy: agrees with Paul. Paul: trust anchors are split on the field. Tero: "semi-wire format". Paul: would prefer presentation format there, too. Hum: don't care wins :-) The authors can go with presentation format. -- Daniel Migault on Implicit IV Dave: We will issue a WGLC on this after the meeting. -- Scott Fluhrer on PQ-hardening IKE Paul W.: they are working on an implementation. Valery: concerns with this approach. The PPK is used as an additional credential. From an operational point of view, this means 2 sets of security creds. A headache. People will probably get rid of certs as a result. Which really is "null authentication". The problem needs to be mentioned in the doc. Initial null authentication (RFC 7619) is problematic. Scott: please contribute text. Valery: I'll try. Paul: could say: MUST NOT use with auth-null. Valery: this is not appropriate, because there is no reason to make NULL auth "MUST NOT" because PPK provides real authentication in this case. Tero: ready for LC? Scott: yes. Dan Harkins: why a requirement on what the PPK is (base64)? Scott: suggestion from last WG meeting. Tero: good for interoperability of config files. Dan: or really to ease transport of PPKs? Key wrapping formats. In that case, why limit the format. Paul: easy to misinterpret if the format is more flexible. Michael Richardson: should be easy to use. Supports Paul. Valery: key distribution is out of scope of this protocol. Tommy: it should be easy to configure, but should be a strong key. Likes the current proposal. Up to implementation to make sure you can easily distribute. -- CJ Tjhai on Hybrid quantum safe key exchange Tero: what is large (payload)? More than 64KB? CJ : some of them are hundreds of KB. EKR: This is all hedge. Identity protection is secondary. Dan: this is ID protection for PQ passive attacks. Tero: multiple identities, renew them periodically. Payload size is limited, but not the IKE message. Valery: can the PK be compressed? CJ: no. Valery: why a new payload? CJ: could use KE. Valery: KE would be better. Assuming you trust the new method. Mark O.: [missed] Paul W.: wondering if this work is premature. Tero: we design algorithms for crypto-agility, so we want to design the hooks for experimentation. Paul: this is more than agility. Don't want to commit to experimental things. Tero: assumes these are plug-in replacements for DH. CJ: yes. Paul: adding a transform? Tero: the WG will decide on bits-on-the-wire. Brian: an IANA registry for algs that we may reject in the future? Philip Lafrance: supports the doc. Came up with similar solutions. Scott Fluhrer: complexity with having 2 algs when we don't fully trust the PQ alg. -- Kai Martius on EC+PQC EKR: if an alternative to DH, make sure to signal: I cannot use this alone. Dan: moving the payload to IKE-AUTH solves fragmentation and backward compatibility issues. And what we lose is PQ ID protection. Paul: if we add a new transform type, we are doubling size. Tero: it would take us back to IKEv1. This is currently out of charter, we might consider for rechartering. Hum: adding non-PSK PQ mechanism into the charter. Unanimous in favor. -- Tobias Heider on G-IKEv2 Implementation Brian Weis: mentions his outstanding G-IKEv2 draft. Draft was not intended for IOT to start with. Quynh: why implement both HMACs. Truncation of SHA to 96 bits is not good. Tobias: did not think of algs, they came from the OS. Tero: this is normal (not minimal) group ikev2. The draft is out there because MSEC is dead. Would prefer to advance it in the WG. EKR: as AD, prefers things to go through a WG. Hum: run g-IKEv2 in the WG? (Not "minimal"). Unanimous support in favor of adding to the next charter. -- Valery on responder-initiated IP address update in MOBIKE Tero: it's a bad idea to spoof packets. Packets will be dropped by 1st hop routers. Yoav: they don't drop in reality. Tero: they will in future. Protocol should not rely on these. Valery: these are not spoofed. Tero: OK if you own both interfaces, but can do it already without MOBIKE. The only problem is if you lose the address, and then you don't own it. Would not be treated well by IESG. Tero: the WG might want to take it on. MOBIKE is not in charter but is related to IPsec. Wants to talk to the AD before taking a hum. Bret Jordan: supports the draft provided no spoofed packets. -- Tobias Guggemos on Diet-ESP Tommy: supports moving forward with the draft. Tobias: complexity is currently low. Tommy: compression seems to be OK right now. Daniel: compression problems with IPv4-in-IPv6 or vice versa. Should we add complexity at this point? Tommy: leave that simple. Wants to see things converge to all-IPv6. This could incentivize this migration. Tero: this works changes payloads but not the protocol. Do we add to the charter? Hum unanimous in favor. -- Other issues Yoav: mentions thread around i2nsf and SDN control of IPsec endpoints. Planning a virtual interim meeting, attended by both groups. Sometime in the next few weeks. Sahana Prasad: negotiation of PSS vs legacy RSA. Tero: we might need to think of a charter item. Paul: agrees this is a problem, should be added to charter.