> On Jun 7, 2015, at 10:09 AM, Ilari Liusvaara <[email protected]> > wrote: > >> On Sun, Jun 07, 2015 at 08:26:51AM -0700, Dino Farinacci wrote: >> Ilari, Brian is on vacation so I’ll take a stab at this. I’m sure he’ll >> reply when he returns. >> >>>>>> Folks, this draft contains the following changes: >>>>>> >>>>>> B.1. Changes to draft-ietf-lisp-crypto-01.txt >>>>>> >>>>>> o Posted May 2015. >>>>>> >>>>>> o Create cipher suites and encode them in the Security LCAF. >>>>>> >>>>>> o Add IV to beginning of packet header and ICV to end of packet. >>>>>> >>>>>> o AEAD procedures are now part of encryption process. >>>>> >>>>> At least I can follow how the algorithms work. Remaining issues/notes: >>>>> - It composes AEAD mode instaed of using ready-made one. The composed >>>>> mode is if nothing else slow (SHA-1 is already slower than some >>>>> ready-made AEAD modes). >>>> >>>> These are the algorithms we’re comfortable with for now. We could >>>> have specified the combined AEAD mode cipher modes, but they add >>>> complexity in the form of maintaining a counter for the nonce. >>> >>> What kind of memory is the association data in? Something that isn't >>> volatile or which can't sustain fast updates? >> >> The AD is the LISP header. And for each packet there is a 24-bit nonce >> (designed for other purposes previously but can be used in this application >> as well). It can sustain fast updates. > > 24-bit space would wrap around quite fast. But maybe that could be > implicitly extended.
We are not using it as a counter. It is a random number selected for each packet. But we have an IV in the payload that can (recommended in spec) be used as a counter. It is 16 bytes in length. > >>> Any reason why "count and if you lose position, just rekey" wouldn't >>> work. >> >> The IV could be used for this purpose. But right at the moment, there is no >> way for the ETR to tell the ITR to rekey. So the rekeying interval is >> equivalent to the RLOC-probing interval. > > Well, most AEAD algorithms have too short nonces to randomly generate > (it is usually 96 bits, which is just too short for random generation). We use the control-plane LISP nonce which is 64-bits. > >>> Note that designing AEAD algorithms is quite nontrivial. And making >>> one with bad performance is easy too. >> >> I don’t think we have that here. > > The fastest secure hash currently known is slower than Chacha20-Poly1305 > (and if one has hardware AES-GCM, that is faster still). Do you recommend poly1305 for a hash? > >>> - Key derivation looks to be missing hashing in important parameters >>>>> (like group and exchange keys) into secrets. >>>> >>>> Not sure which parameters you mean? The DH shared secret is the >>>> key for the KDF, I’m not sure why we’d provide any other keys as input >>>> to the KDF. >>> >>> The problem is that by manipulating things like ciphers, groups or >>> exchange keys (even one-sided), attackers can make strange things >>> happen. >> >> Meaning if you use the DH public-keys too often, they can be hacked? > > Meaning that if DH public keys are copied and pasted into unexpected > places, strange things can happen. > > Best to ensure that key computations just fail to produce matching > keys if this happens. > > I don't know much about this, considering how obscure the attacks are > here. Okay - let's crawl before we walk and see how this turns out. I have finished an implementation of the -01 spec and will present in Prague. I hope to try other cipher suites that are not in -01 and report on it. > >>> Hashing such parameters is especially important if some sort of >>> connection "figerprint" is provoded for MITM detection. >> >> We use the Map-Request nonce for such a fingerprint. And that will be seen >> only in two packets. Each new RLOC-probe contains a new nonce (this is a >> 64-bit nonce), and if the ITR changes its public-key (1024 or 2048 bits in >> length), then a rekey event is occuring. > > Not good. For secure fingerprint, one needs to hash at least the > crypto parameters (e.g. groups and ciphers) and exchange keys > (the public keys). We were told buy many to not transfer such information but to do a registry that defined cipher suite values. > Otherwise attacker replacing those parameters and get identical > fingerprints on both sides, despite MITM position. Don't forget that the attacker has to also compromise the map-server. Because the Map-Replies are signed with a trust relationship between the real ETR and the map-server it registers EID-prefixes to. > >>> If unsure what to hash, just dump the LCAFs into session key >>> derivation as a whole. >> >> Well the context for the hash is in the spec. So please comment specifically >> on it. Thanks. >> >>> At least TLS took nasty attacks from not hashing in the exchange keys >>> (g^x, g^y or xG, yG). >> >> I have found with prelim testing that g^x is taking 8 times longer than xG. >> So I would like to hear from you about what ECDH groups are safe. > > CFRG recommended ECDH groups are Curve25519 and Curve448 (which is pretty > extension of Curve25519 to larger prime). > > https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/?include_text=1 Will check it out. Thanks. > >>> Also, found another potential issue. There is no nonce field, which >>> means that public keys can't be safely reused, but must be regenerated >>> for each use. >> >> That is what we are doing. Or do you mean here for each packet encapsulated, >> that is considered “a use”? > > Each key exchange is "use". Okay then I think we are good. > >>> This would be especially troublesome for computationally-limited and >>> memory-limited devices. >>> >>> If one has no space for auxillary tables, one needs to do DH operation >>> to generate a key (which doubles key exchange CPU usage). With tables >>> one can push it to about one third of DH operation, but at cost of >>> tens (ECDH) or hundreds (DH) of kB of static tables. >> >> Hmm. We don’t want to require tables of any kind. > > One does not need the tables, it just speeds up calculating public > key. Which one needs to do for each key exchange due to lack of nonce. We can leave this as an implementation option. Meaning we shouldn't spec "how its done". > With nonces and reusing public keys, one could e.g. recalculate the > public key every 10 seconds. > >>> Of course, when reusing DH keys, one shouldn't keep them valid for >>> too long. IIRC, Daniel J. Bernstein recommended ten seconds a while >>> back, and considered several hours some products did as too long. >> >> We can do that with RLOC-probing, but 802.1AE MacSec is rekeying every >> 600ms. But this could be considered a completely different application. Do >> you have any thoughts about that? > > This was about how long to keep DH keys, not how long to keep the > resulting session key. Got it. > >>>> We do need less computationally demanding ciphers for deices that do >>>> crypto in ARM based platforms, which explains the 1024-bit DH (and yes, >>>> we realize it is weak). As stated in the Future Work section we will >>>> be looking at these ECDH functions and should have some results >>>> before the Prague meeting. If we can replace the 1024-bit DH we will. >>> >>> Something came up when investigating the TLS Logjam mess. Experts >>> guess that NSA has computed "logarithm tables" for a few common >>> 1024-bit DH groups. Those tables allow breaking DH very quickly. >> >> We don’t have any problems using longer keys since the Map-Request and >> Map-Reply packets right now for RLOC-probing are relatively small to the >> effective MTU size. > > I agree with the recommendation that fixed (discrete) DH groups should > be 2048 bits at least. Ack. > >>> The authors of research on TLS Logjam recommended regarding use of DH: >>> - Use ECDH (beweare of weak 160-bit curves and backdoored curves) >>> - Named (fixed) groups need to be 2048 bits at least (beware of back- >>> doored groups) >>> - If needing to use 1024-bit DH, generate your own group and change >>> it frequently. >>> - Don't use <1024 bit DH at all. >> >> Does that mean we have to create dynamic cipher suites if we use 1024-bit >> keys? > > Yeah, and that creates all sorts of problems. > > > -Ilari Thanks again and let's see Brian's comments. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
