IPsecME IETF-92 Dallas Minutes taken by Paul Wouters WG status report http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-0.pdf - authnull going into IETF LC https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ PaulW: we have an implementation, please interop test: oe.libreswan.org PaulW: we changed the word "audit" as someone told us that would require them to deliver a stack of papers as audit. Otherwise only language changes based on Kathleen's suggestions and questions. - ddos-protection https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ chairs: draft not yet ready for WGLC. chairs: please keep discussion on the mailing list - not github chairs: more review needed, lots of new text. some interaction of authnull and ddos chairs: lets set an example in this WG for ideas useful in other WGs Tero: HIP also had some non-hashing method Yoav presenting his slide deck Some discussion about clients and how many bits to solve [some discussion lost due to laptop malfunction] Tero: dont have to limit IKE window size to 1 - you can just wait processing these Brian Wise: NO_ADDITIONL_SAS can be avoied by a new exchange? Tero: yes Miquel: you send puzzles to everyone - you dont know who that is. Same policy for phone and computer? Tero: there is no way out of that. channeled jabber: Tero adds: you can use different IKE window size for AUTH_NULL clients versus other Yaron: why not use puzzles after IKE SA is established? Tero: need to think/discuss about Tero: client could send multiple answers even before puzzle solved - and hope to get it before puzzle solved Brian: Yaron: complexity discussions. for cases when you dont like initiator response just fail it. don't add complexity The zero value. as initiator how do i decide what my peers are doing and how can i get in front of the queue? Tero: we have different initiators, the same puzzle level cannot fit all client types Yaron: desktops will have the upper hand to swamp the responder Brian: I thought the zero was silly. do we have to do computation first? Yaov: we have the key so it is one turn of the PRF and counting the number of zero bits Brian: zero is like half the solution, there needs to be more description on what happens on the responder side Tero: Two parts of the document. one describe the protocol for interop/implementors. second part (appendix?) on implementation details, on why we use certain heuristics for something and how various devices should try and implement. PaulH (no hats): Tero gave a very clear split suggestion - however with zero value the client side is that goes in between both. I dont want to see an appendix here. Implementors really needs to make a lot of guesses. belongs in main body of the document. Brian: I'm fine with tero's description. Valery: Mic: If responder figures out that the initiator solved relatively easy puzzle, but it takes it quite a lot of time Valery: Mic: The responder could figure out that the initiator is weak and give it more priority Valery: Mic: I agree with Tero that some kind of algorithm for responder must be in the draft. Yaron: determination. Scotts idea to make it more deterministic is worth while - even if it does not fix all issues of phone vs laptop Tero: as long as we keep the puzzle the way it is we have to set it to the worst case. occasionally initiators get lucky and get the easy puzzle. PaulH: while not busy pre-calculate to determine if it is easy or hard puzzle and remember Brian: Valery: Mic: I think that we cannot make puzzles deterministic givin the diversity of computational power of different clients Valery: Mic: Look at puzzle as to lottery - some are more lucky Tero: and botnets are usually desktops - the most powerful clients we have - chacha20poly1305 http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-2.pdf Yoav presenting Yaron: does arm have aes acceleration? Yoav: no. it has something called neon - not in phones but in tablets. has some advantages Steve Kent: the "civilian part" keep in mind several industry sectors make use of FIPS approved algos for liability purpose. If the motivation is performance, that is not a good argument anymore. Russ Housley chatted with NIST people and made optimized miplementation og P-256 so the performance of Curve25519 is not different enough. Performance is not a good reason. Tero: you cannor use curve25519 .... same for blake.... ? Tero: I hate the names A B and C. C for civilian is not a good name. Move UI out and do UI in separate document Yoav: I thought we'd have the answer of CRFG by now.... Quynh Dang from NIST: We received documents and proposal claiming they have to implement P-256 faster than Curve25519. Has not been verified. It is just a claim. PaulH: who will support with review or code: Tero,PaulW, Michael and Valery - AES CCM http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-3.pdf Daniel presenting Tero: get rid of aes-cbc. all small devices use ccm anyway Steve Kent: the process that generates the nonce or IV is within the boundary of the [application?] [ more talk about FIPS / certification ] We looked at this in the past - we provided citations to Daniel