Minutes IETF97: ipsecme
minutes-97-ipsecme-00

Tero: Agenda talk
Tero: ddos and safecurves in AUTH48
Tero: 4307/7321 bis documents
David: any concerns with 7321bis for WGLC ?  none from room
Tero: encaps edDSA adopted
Tero: Split dns, implicit itv, waiting for adoption

[split dns presentation]
Some push to get early code point done by Tommy, Paul and Valery

[tcp encaps presentation]
Yoav: why mention anything but TCP (http, quick)
Tommy: we kind of want to tell people this works for other transports
Yoav: I'd need a new document anyway for SCTP or something else

Valery: You must specify more precisely to ensure interop
Tommy: TCP is opened by initiator. Server should accept any tcp connections
        (with sane limit)
Valery: so you need to support multiple TCP connections for a single SA
         I think more specifics
[Hu Jun]: Which TCP session to use? what is the use case to support
    	  multiple TCP connections.
Tero:  can me mandate MOBIKE?
various people including Yoav, Paul and Tommy: please do not
Tommy: TCP 3way handshake gives some guarantee, so MOBIKE not really required
Paul: Be careful of ignoring retransmits over new NAT mapping.
       When initiating new TCP connection, resend last IKE packet, so
       responder can determine which TCP session to use.

[Yoav edDSA draft, implicit IV draft presentation]
Paul: context isn't really needed, IKE/IPsec very specific
Tero: Its far fatched, but CRFG says protect against it anyway
Dan Harkins: mic: the answer is that it's a signing oracle and that
    	     is a bad (if not good) thing. Context is easy fix.
mcr: maybe an HSM could be tricked like that?
Tero: Attacker can also only use half of it (send or receive). Lots of random
       things are there not under control of attacker
Yoav: This same question comes up in curdle and TLS :)
Dan Harkins: mic: not clear, is ipseme's decision based upon what curdle does?

[Valery presentation Ambiguity in IKEv2]
Paul: why not move into IKE_AUTH, and send different IKE_AUTH after failure?
Valery: spec does not allow that - must start with new IKE_INIT
Yoav: [missed what he said]
Tero: Not a big problem - AUTH is mostly preconfigured/provisioned
Dan Harkins: waiting for "will be gone" is not right— given IKEv1's
    	     tenaciousness— so if something hurries up -PSS adoption
	     we should do it. Size of message seems to be a small
	     price to pay. 
[Hu Jun] Not a big problem

[David presentation QR]
Dan Harkins: mic: since the child SAs use KEYMAT to generate IPsec
    	     keys and KEYMAT has the PPK then why mix in the PPK again
	     to generate child SAs? 
David: Don't have a good answer right now.
Scott Fluhrer: Because we want to give an implementor the option of
      	       protecting the IKE traffic 
mcr: I asked for identity protection. Interesting child SAs would
     be protected, what I would like to have is an architecture that
     leads us towards ID protection even if we dont get it right now.
     Eg use pseudonyms on first round to bound them on second round.
     site-to-site doesnt have this problem. On mobile site it is
     increasingly important, see for example TLS 1.3. Eg if we have a
     bit for ID protection would work. 
Dan: A future QR replacement for DH could help give us the identity
     protection. 
Paul: Isn't PPK ID an anonymous ID anyway
Tero: Could add new identity type to use in the initial IKE_AUTH, 
      and then send some new psuedonyms in the next rekey once the
      channel is safe. We don't need to do this as part of the QR
      draft, but can add it later in a separate identity protection
      document. 
Tero: Agree to not have ppk management now, but we could use the
      ppk notify payload for some value later. Outside of IKE SA, just
      used to identify the ppk 
Debbie: the long term goal is not to have this. Its an interim.
Paul: PPK identifier can lead to privately convey ID
Tero: it is good enough that we can do WG adoption call

[compact format of IKEv2 payloads presentation by Valery]

Paul: Isn't it greedy to ask for 3 reserved bits?
Tero: Reserved field we only use critical bit. Using them is not a problem
      will people really use this? IoT does a lot of weird tricks.
      Other forms of compression might work better. For IoT, we can
      reduce SA packet to 1 byte :) Maybe something completely
      different would be better 
Valery: for IoT, things split in 128 byte blocks. So a few bytes might
	actually gain you a lot.
Tero: Actually, it is 11 + 3 bytes extra depending on mode.....
Tommy: Goal of compressing is great for IoT. I am worried with complexity.
       You can already reduce transforms if you know what you
       want/need. You could rather have a new format with "profiles"
       where you send a profile number that maps to [a proposal] 
mcr: you need to compare work against generalised header compression
     which does a good job at removing 0's. Can prob get close to lzh.
     Worth comparing that. If ioT is already using [????]. Use a
     encryption algorithm transform to signal this? Same as diet ESP,
     is this really going to be used? I dont think it will be used. I
     don't think it is worth spending time on now. Maybe in 5 years? 
Brian Weis Cisco: Rather see a completely different that would achieve
      	   	  more. 

[Enapsulating ESP in UDP for load balancing presentation]
Dan Harkins: SPI already identifies a flow. No need for any other
    	     field for flow identification. Any LB decision made by
	     the destination MUST be transparent to the source.  
Tero/Paul: source port can be anything already, does not need to be
	   4500, so use that?
Lorenzto: Use flow label in ipv6
????:

Tommy: if there is a NAT too, how would this work?
Presentor: We assume there is no NAT

[GDOI groupkey presentation]
Valery: messages can be lost. it is not reliable and can be dangerous
Kathleen: please feedback on the list
Tero: and CC msec list