Re: [lisp] I-D Action: draft-ietf-lisp-crypto-01.txt

[Dino Farinacci <[e-mail]>]

> On Jun 7, 2015, at 10:09 AM, Ilari Liusvaara <[e-mail]> 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