IPSECME Meeting Friday 25 July 
Minutes taken by Jim Schaad

AGENDA Presentation (Paul Hoffman = PH)
http://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-3.pdf
NULL Authentication Method in IKEv2 Protocol (Valery Smysov = VS)
http://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-0.pdf
Paul ? : Should change Recommdned to Must on no data

    Don't accedently leak any data in this

    Early code pont assigment - yes please do now.  We want to release this

VS: It will be ignored by reciever - if make MUST what should happen if not zero length?
Tero (TK): Doing early code point is not a problem - just asked for it.

    Want to have an ide there.  Useful to be able to put something there even if it is not real data

    Allows for logging of access id along with data 

VS: Draft currently allows for data to be present
Hugh Lentermier: Tero - why not use verder id for that purpose?
Tero: We don't have this.  It it is not 
Hugh: Why use id type zero - this is normally considered a bug value
VS: currenlty a reserved value
Hugh: Makes this a way to doing 
Yaron = YS: want's the id paylong not be empty.
Mike Richardson =RS: Correct use of Opportunistic security not encrypt since don't know if anything is going to be negotiated.
MOBIKEv2: MOBIKE extension for Transport mode (Daniel = DM)
http://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-2.pdf
TK: Do you need to negoiate support for v2?

    What happens if server only supports v1

    Asume use transport mode - negotiate based on that - default to tunnel mode if not available.

    No protocol bits are going to be changed

PH: Is fallback as clean in this way?
TK: Yes - already says what to do today in the specs

    Not sure what current impleentations will do today with the new extension added.

    Need to have note on transport mode for the child SA setup

PH: Do you believe that people would accep tthis?
TK: Doing the updte IP Address as a traffic selector changes the kernel code
PH: Sounds like this should work and may be less work for MOBIKE
Shelia: No additionl seucrity considerations in this draft.

    Different threat model than MOBIKE

    Need more security considerations for saying what is changed if no header exists.

Client puzzles (Yoav Nir = YN)
http://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-1.pdf
TK: Could send both cookie and puzzle back and helps to solve cookie better

    Client sends back partial cookie

    Make different classes of entities based on what vlues are returned

    Added extnesion should be ignored by old clients

??: Using classed responses allows for some tuning
RS: how do you think about rollout.

    Start with clients that don't know puzzles

    Attackers start solving puzzles - arms race occurs

    Attackers are better equiped - don't pay for equiement and generally high level systems

    Need to have additional puzzles that will last for decade as work gets harder

    Graded responses for low level devices to allow for ranking of items - low level device can do a "parital" solution

Richard Briggs: Add time factor on difference between the request and the response to do more filtering
YN: Are we punishing people for having fast cpus?
PH: You only get one round trip on this

    Still somewhat a therotical question at this point

RB: If server not keeping state then this is harder
Wise (Cisco): Like the approach

    Had a limit on the maximum amount of time to produce solution

    Need to make sure that you cannot distribute the solution of the puzzle to other systems in the botnet

YN: suggestion in draft is that initiator cookie and the ip address are included in the result - defense againist shared puzzle solving
TK: Allow for parital solving and give a time limit on solving the puzzle - client might only get n of m bits solved.

    After amount of time user will re-try anyway.

YN: Problem with server logic - flood with partial solutions w/ only partial solutions and flood the list
Brian Wise: Don't want server to keep intermidate state on the hashs

    Start with simple puzzle and get harder - kill the low cap devices.

Hugh: Not careful will make it more brittle
Any other business
YN: Presented on ChaCha20 and Poly for algorithms 

    Response was go to CRFG

    CRFG has accepted this as documents

    Will ask again here when that algorithm document is published