Minutes IETF99: ipsecme
minutes-99-ipsecme-00

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.