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