Friday, March 27, 2015< ^ >
yaron.sheffer has set the subject to: IPsecME Meeting at IETF 91 in Honolulu
Room Configuration
Room Occupants

[16:46:55] Valery Smyslov joins the room
[16:47:06] Meetecho joins the room
[16:48:52] Argentina HUB joins the room
[16:50:15] paulwouters joins the room
[16:50:36] <paulwouters> hi Valery :)
[16:51:07] <Valery Smyslov> Hi
[16:51:12] <Valery Smyslov> hi
[16:52:09] kivinen joins the room
[16:52:14] Michael Richardson joins the room
[16:53:43] <kivinen> meeting starting.
[16:57:01] <Valery Smyslov> does that mic work?
[16:57:17] <Valery Smyslov> very weak sound
[16:57:17] <kivinen> can you hear Kathleen now?
[16:57:44] <Valery Smyslov> I can hear but I cannot figure out the words - too weak sound
[16:58:03] <kivinen> Can you hear paul?
[16:58:10] <Valery Smyslov> yes
[16:58:16] <Valery Smyslov> very good
[17:01:18] Kathleen Moriarty joins the room
[17:06:14] <kivinen> I assume you can now hear Yoav?
[17:06:20] <Valery Smyslov> Yes
[17:17:36] paulwouters leaves the room
[17:17:41] <Valery Smyslov> the cookie could contain timestamp, so that responder could figure out howm much time the initiator solved it
[17:20:16] <kivinen> If you want anything to be channeled to mic, add "mic:" in front of it.
[17:22:28] <Valery Smyslov> ok, thank
[17:25:32] cw-ietf joins the room
[17:26:04] cw-ietf leaves the room
[17:27:01] cw-ietf joins the room
[17:29:11] <Valery Smyslov> Mic: But 10 requests would consume more memory on responder than 1
[17:32:19] <Valery Smyslov> Mic: Puzzles is controversal thing
[17:32:41] <Valery Smyslov> Mic: It's better to use more simple countermeasures when we can do it
[17:33:45] paulwouters joins the room
[17:37:46] <Valery Smyslov> Mic: If responder figures out that the initiator solved relatively easy puzzle, but it takes it quite a lot of time
[17:38:12] <Valery Smyslov> Mic: The responder could figure out that the initiator is weak and give it more priority
[17:42:20] <Valery Smyslov> Mic: I agree with Tero that some kind of algorithm for responder must be in the draft.
[17:43:49] joins the room
[17:44:04] <Michael Richardson> I also like Tero's proposal.
[17:44:21] <kivinen> mcr: do you want that to be said on mic?
[17:44:45] <Michael Richardson> not necessary, given time constraints.
[17:47:49] <Valery Smyslov> Mic: I think that we cannot make puzzles deterministic givin the diversity of computational power of different clients
[17:48:09] <Valery Smyslov> Mic: Lokk at puzzle as to lottery - some are more lucky
[17:50:19] <kivinen> moving to the sales dance...
[17:50:29] <Michael Richardson> hmm. I wonder if there is some way to penalize attackers that answer too quickly (are too powerful).
[17:50:33] <kivinen> I mean ChaCha20 + Poly1305...
[17:51:26] <kivinen> if they use normal desktop machines they are as powerfull as most of the normal regular users. The problem is that there is some group of slower devices, which will get swamped by faster ones.
[17:52:05] <kivinen> and also it is easy for attackers to slow down the solving time if they want.
[17:52:53] <Valery Smyslov> The idea is that if you solve hard puzzle too quickl, than your priority is not the highest
[17:53:37] <Valery Smyslov> I cannot tell it a penalty, but really responder can weigh the results so that very powerful clients not necessary always win
[17:54:22] <Valery Smyslov> and if attackers slow down solving time than we have the DoS attack decreased - that is what we wanted
[17:54:47] <kivinen> an what kind of algorithm you use depends on your client base. If all your clients are desktops you can do something, if all of your clients are supposed to be mobile phones, you might do something else.
[17:54:54] <Valery Smyslov> the more solving time the less requests we get from attackers
[17:55:29] <Valery Smyslov> Th algorithm needs to be specified yet :p
[17:56:20] <kivinen> and I do not think it should be specified in the draft, it is implementation specifics that depends on the vendor and environment. We can hints and things to consider for the vendors, but I do not think we want to mandate any specific implementation.
[17:57:01] <Valery Smyslov> It is implementation dependent - yes, but some example of such algorithm should be given
[17:57:12] <Valery Smyslov> At least in appendix.
[17:58:04] <Valery Smyslov> Or just give some desired properties of the algorithm and let implementers to invent it themselves
[18:06:46] <Michael Richardson> wow, if we don't standardize the puzzles, then we are basically further locking clients and gateways.
[18:06:47] <Valery Smyslov> rais
[18:07:13] <Michael Richardson> I commit to review ChaCha document.
[18:07:47] <kivinen> Valery: I assume you meant to raise your hand to review chacha document.
[18:07:53] <Valery Smyslov> yes
[18:09:37] <Michael Richardson> okay, time to go get kid at school.  Thanks all, it's been a great IETF. Enjoy your flight home, I sure did.
[18:09:52] Michael Richardson leaves the room
[18:18:48] Kathleen Moriarty leaves the room
[18:18:52] leaves the room
[18:19:02] cw-ietf leaves the room
[18:19:06] <Valery Smyslov> thank all, good bye, have a good day
[18:19:14] Meetecho leaves the room
[18:19:17] kivinen leaves the room
[18:19:31] Valery Smyslov leaves the room
[18:24:18] paulwouters leaves the room
[18:28:08] joins the room
[18:33:23] Argentina HUB leaves the room
[18:39:52] paulwouters joins the room
[18:42:12] leaves the room
[19:39:25] paulwouters leaves the room
[22:27:21] paulwouters joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!