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

[Dino Farinacci <[e-mail]>]

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.

> 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.

> 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.

> - 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?

> 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.

> 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.

> 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”?

> 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.

> 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?

>> 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.

> 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?

> -Ilari

Thanks for your valuable comments.

Dino