> I did a review of crypto usage of lisp-crypto (-02), and found the
> following issues (some I have noticed before, some were new to me):
Thanks for doing that Ilari. See my responses inline.
> - 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.
> - Instead of "homecooked" encryption, use AEAD modes. AES-GCM is a lot
> faster than AES-CBC + HMAC-SHA1-96.
I didn’t realize we were home cooking this. We can certainly go with AES-GCM.
Do you think we should add a new cipher suite for it or just change the
existing ones that refer to AES-CBC to AES-GCM?
> - AEAD_CHACHA20_POLY1305 is not composition of CHACHA20 and POLY1305,
> it is a single AEAD algorithm (as is AES128-GCM).
Did we imply that? Can you point to the text? I for one, am not expert enough
to know the difference so if text implies that, please point that out.
> - How to encode Diffie-Hellman public keys? I presume big-endian
> integer encoding.
I will make that more clear in the spec. Thanks.
> - Don't truncate Diffie-Hellman secret, just feed the entiere thing
> to the KDF
I want Brian to comment on this. I have no opinion about the matter.
> - 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.
> - If you need identifier for association (e.g. for displaying to
> admin for authentication purposes), you must hash in the (EC)DH
> public keys used into the identifier. Otherwise MITM attacker can
> defeat the authentication.
We use the source RLOC and the Map-Request nonce to identify the association.
> - If the same system can be ITR and ETR at once, how one ensures that
> if two such systems establish associations to each other, the keys
> won't wind up being the same? This could be solved by requiring
Because the key-pair is unidirectional. If router A is an ITR and sends a
Map-Request to router B, that key-pair is for data traffic encapsulated from A
to B. If B is an ITR encapsulating to A an ETR, a differne key-pair is used. A
new random number generator, nonce, and key exchange is performed for each
direction.
> separate keys for ITR and ETR operation, or including the public
> keys in the context in fixed order (e.g. first ITR, then ETR).
> - AEAD_CHACHA20_POLY1305 IVs are 12 octets, right? That's too short
> to randomly generate. Instead, the encryptor should just use its
Yes, you are right. I padded to 16-bytes in my implementation. Do you see harm
in that. That way the packet length/format doesn’t have to change for different
cipher suites.
If you are okay with padding, I can make that more clear in the spec.
> preferred generation method that takes long time to cycle (counter,
> 96-bit LFSR, etc...).
> - Are the associations unidirectional (data is only ever sent one
> way) or how is uniqueness of IVs between directions handled?
Yes, unidirectional. IVs are per packet, any packet, in any direction.
> - 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).
The diagram in Section 6:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L / |N|L|E|V|I|P|K|K| Nonce/Map-Version | \
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
S \ | Instance ID/Locator-Status-Bits | |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initialization Vector (IV) | I
E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C
n / | | V
c | | |
r | Packet Payload with EID Header ... | |
y | | |
p \ | | /
t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value (ICV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Is the same for any cipher suite.
> - AEAD_CHACHA20_POLY1305 decryption both checks the ICV and if the
> check passes, decrypts the data. So performing step 2 also performs
> step 5.
Hmm. So are you saying that if the cipher suite negotiated is chacha20, we
should not add a ICV? That would be great, beacuse we can make cipher suite 4
go even faster.
> - I don't see requirement that ITR nonces must be distinct for the
> same ITR DH key (otherwise encryption keys will be the same if
> the ETR DH key is the same)?
Well in RFC 6830, we state that nonces are distinct for each Map-Request. So we
inherit that information for DH.
> - The CHACHA-POLY reference should presumably point to RFC7539?
> - Maybe use the CFRG-CURVES draft (in RFC-EDITOR queue) for
> Curve25519/X25519.
I will fix. Thanks for comments and please clarify some of my questions above.
Cheers,
Dino
>
>
> -Ilari
>
> _______________________________________________
> lisp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
