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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
