[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    [IPsec] IETF092 draft minutes
From:       paul () nohats ! ca
Date:       2015-03-27 18:20:15
Message-ID: alpine.LRH.2.11.1503271419440.9043 () ns0 ! nohats ! ca
[Download RAW message or body]



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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


[prev in list] [next in list] [prev in thread] [next in thread]