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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
