Subject: [IPsec] IETF092 draft minutes

From: [email-masked]
Date: Fri, 27 Mar 2015 14:20:15 -0400 (EDT)

IPsecME IETF-92 Dallas draft minutes

[lots of technical projection issues]

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 (while my laptop crashed and burned)

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: <did not hear Tero> 
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:  <missed>
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....
??? 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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 29 Mar 2015 00:08:06 +0300

> On Mar 27, 2015, at 9:20 PM, [email-masked] wrote:

Hi

In the meeting Kathleen asked how long the draft was. With all the algorithm details moved to the CFRG draft, the entire document is six pages, including introduction, IANA and security considerations, references, and the UI suite stuff (that I agree with Tero that should be moved out).

The real “meat” of the document is section 2, which spans a little over one page.

HTH

Yoav