* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ipsecme Status Pages

IP 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

minutes-99-ipsecme-00 minutes



          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.
          
          



Generated from PyHt script /wg/ipsecme/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -