Re: [lisp] Let's review crypto in lisp-crypto

[Dino Farinacci <[e-mail]>]

Understand your comemnts. I’ll create a -03 with changes that reflect your comments and turn it around ASAP so you can make sure I addressed your comments.

Expect it in the next few days but not before today’s working group meets.

Dino

> On Nov 2, 2015, at 2:39 AM, Ilari Liusvaara <[e-mail]> wrote:
> 
> On Sun, Nov 01, 2015 at 08:42:44PM -0800, Dino Farinacci wrote:
>> 
>>> On Sun, Nov 01, 2015 at 01:13:56AM -0700, Dino Farinacci wrote:
>>>> 
>>>>> - Ciphersuite 1 uses 1024-bit Diffie-Hellman, which is too weak
>>>>> (after you have cracked one key (and it doesn't take that much,
>>>>> especially if you can throw ASICs at the problem), you can crack
>>>>> each subsequent one in a few CPU minutes. With 2048-bit DH, at
>>>>> least the first key tends to be too hard, and with ECDH, tricks
>>>>> like this don't work).
>>>> 
>>>> Yes, both Brian and I replied that we were using this more for
>>>> experimentation on low-powered or CPU challenged devices. We will
>>>> not recommend its use. It’s just there for implementations to start
>>>> with something. But havind said that, I would like to recommend
>>>> the smaller keys that come along with chacha20/poly1305 so maybe
>>>> the subject is moot. 
>>> 
>>> I think that even having low-security options is a problem.
>> 
>> How about we change the Cipher Suite definitions TO this (and address multiple of your comments):
>> 
>>   Cipher Suite 0:
>>     Reserved
>> 
>>   Cipher Suite 1:
>>     Diffie-Hellman Group: 2048-bit MODP [RFC3526]
>>     Encryption:           AES with 128-bit keys in GCM mode [AES-GCM]
>>     Integrity:            HMAC-SHA1-96 [RFC2404]
>> 
>>   Cipher Suite 2:
>>     Diffie-Hellman Group: 3072-bit MODP [RFC3526]
>>     Encryption:           AES with 128-bit keys in GCM mode [AES-GCM]
>>     Integrity:            HMAC-SHA1-96 [RFC2404]
>> 
>>   Cipher Suite 3:
>>     Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
>>     Encryption:           AES with 128-bit keys in GCM mode [AES-GCM]
>>     Integrity:            HMAC-SHA1-96 [RFC2404]
> 
> AES-GCM is AEAD algorithm, so it also covers the integerity.
> 
>>   Cipher Suite 4:
>>     Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
>>     Encryption:           Chacha20-Poly1305 [CHACHA-POLY]
>>     Integrity:            Covered under Encryption Algorithm
>> 
>> Please ack before we take action. And would like Brian (or anyone else
>> in the WG) to weigh in on this as well.
>> 
>>>>> - The NIST SP800-108 KDF handles the counter and length internally,
>>>>> those are not part of the context input.
>>>> 
>>>> You should point to text so we know where in the spec you are
>>>> commenting against. It is hard to get context from your comments.
>>> 
>>> Section 5 in -02. The listing for "Context" (meaning the fields
>>> in context).
>> 
>> I think we are saying we are building a context similar to the NIST
>> standard but not using it. Brian needs to comment here.
> 
> What I'm saying is that you seem to be duplicating steps NIST KDF does
> internally.
> 
>>>> We use the source RLOC and the Map-Request nonce to identify the association.
>>> 
>>> That's does not create identifier suitable for comparing between
>>> endpoints for authentication.
>> 
>> LISP-SEC is used as well. See the Security Considerations section.
>> I think we have this covered.
>> 
>>> You mean that A (and B) is supposed to use different DH keys for
>>> their roles as ITR and ETR (if reusing keys, like at least some
>>> implementations are going to do)?
>> 
>> Yes, that is the way we described it by talking about encryption
>> unidirectionally from ITR to ETR.
> 
> I haven't found the security consideration (that if the same router
> is ITR and ETR, it MUST NOT reuse DH keys for both purposes).
> 
> And I'd rather not leave such things implicit.
> 
>>> - IV is incremented for every packet? If using CBC mode, predictable
>>>>> IVs are bad (AEAD algorithms do deal with predictable IVs, but not
>>>>> repeating IVs).
>>> 
>>> I mean, the document seems to say both IVs are randomly generated and
>>> incremented for every packet (which seem to be mutually
>>> contradictionary).
>> 
>> I see. We can do one versus the other. That is, use random IVs. Is that okay?
> 
> No the problem is:
> - CBC IVs MUST be random.
> - 12-octet-nonce AEAD IVs MUST NOT be random.
> 
> The reason for latter is that 96 bit randoms repeat too soon, and
> AEAD algorithms usually break in catastrophic ways if the nonce
> ever repeats (basically all security lost in this case).
> 
>>> 2) Invoke the AEAD encryption with:
>>> - Key set to encryption-key
>>> - Nonce set to the IV (truncated to N_MAX octets if N_MAX<16, padded
>>> with zeroes in the end to N_MIN octets if N_MIN>16).
>>> - AD set to LISP header plus added IV field (the parts of packet marked
>>> as ICV but not encrypt).
>>> - Plaintext set to the packet payload.
>> 
>> Yes, that is what we do.
> 
> If you have IV size be algorithm-dependent, just set the nonce to the
> IV (no padding, no truncation).
> 
>> 
>>> And decryption:
>>> 
>>> 1) Strip the outer IP and UDP headers.
>>> 
>>> 2) Strip tag encryption concatenated  from packet payload (if any).
>>> 
>>> 3) Invoke the AEAD decryption with:
>>> - Key set to encryption-key (from local key-cache)
>>> - Nonce set to the IV field contents (truncated to N_MAX octets if
>>> N_MAX<16, padded with zeroes in the end to N_MIN octets if N_MIN>16).
>>> - AD set to LISP header plus added IV field (the parts of packet marked
>>> as ICV but not encrypt).
>>> - Ciphertext set to the packet payload.
>> 
>> But we don’t use the data-plane nonce for this. Because it may be
>> used for other LISP data-plane features. We use the control-plane
>> nonce which doesn’t show up on the network very often (only when
>> Map-Requests and returning Map-Replies are sent). So this is better
>> for security.
> 
> No, this nonce is the nonce for crypto algorithm and is per-packet.
> The LISP packets transport it in "IV" field.
> 
>>> There is also AEAD_AES_128_GCM, which being AEAD algorithm, is used
>>> similarly to AEAD_CHACHA20_POLY1305. The above algorithms work with
>>> it too.
>> 
>> Does that mean we don’t need an ICV if we used AES-GCM? Similar to
>> your chacha20-poloy1305 comment?
> 
> Yes, it means that. AES-GCM internally does the equivalent of the ICV
> (called "tag" there).
> 
> 
> -Ilari