Hi Yoav,
Hi, Valery.
Thanks for the review. See my reply inline.
Technical issues.
1. For the question raised in the draft:
TBD: do we want an extra 32 bits as salt for the nonce like
in GCM, or keep the salt (=SenderID) at zero?
I prefer to follow GCM-like approach, i.e. to take these 32 bits
from the KEYMAT. It is cryptographically sound and is good
from evaluation point of view - you know where these bits come from.
I thought so as well. In the meantime, the TLS working group is discussing
the same thing for TLS 1.3, and they are proposing to get rid of the salt
(or IV) for AES-GCM as well as ChaCha20.
http://www.ietf.org/mail-archive/web/tls/current/msg15884.html
AFAIK they are discussing the possibility to get rid of explicit IV at all
and to use record number for that purpose. I don't think it will work
in our case. More precisely it could work for ESP, where sequence numbers
are unique, but it won't work for IKEv2, since Message ID is not unique
and can repeat (in cases of cluster synchronization or IKE Fragmentation).
So either we need to define two different mechnisms (implicit IV for ESP
and explicit IV for IKE) or always use explicit IV.
The TLS working group is not making decisions for us, but I think it would
be a shame
to arrive at different conclusions where the cases are very similar. More
technically,
I use a single crypto library for both TLS and IPsec, and having a “salt"
parameter
that is always set to zero for TLS makes me sad.
I agree that it is better to have a single mechanism for TLS and IPsec.
However I doubt if TLS WG would take into considerations our problems,
when making its own decision. On the other hand I think that implicit
IV is unacceptable for us (at least for IKE).
I understand that it would require some adaptation
for multi-sender case, like in RFC6054, but AFAIK currently
Many-to-Many IPsec SAs are rare and look exotic.
And as RFC6054 states, the nonce is not transferred in packet,
so it is not the best place for SenderID (unlike explicit IV).
As RFC 6045 says in section 3, the sender ID is carved out of the explicit
IV,
not out of the invisible salt. So that part of my question made no sense
anyway.
We either want the salt to protect against something, or we don’t. It’s
not reserved for sender ID.
Then, I think, it's better to use the salt as a salt, than not to use it :-)
Editorial issues.
1. Section 2, first bullet.
o The Initialization Vector (IV) is 64-bit, and is used as part of
the nonce. The IV MUST be unique for each SA but does not need to
be unpredictable. The use of a counter or an LFSR is RECOMMENDED.
The IV MUST be unique for each invocation (ESP packet or IKEv2 message),
not for each SA.
Unique for each invocation *with the same key, no? And keys are different
from one SA to another.
In its current form the text could be read that the IV is static
(unique for each SA, but not changing during the lifetime of SA,
so that each message of a particular SA have the same IV).
But in fact the IV must be unique for each message encrypted with the same
key,
so it must change (e.g. incremented) after each use.
I just wanted to emphasize that fact and avoid possible readers confusion.
Minor nits (subjective).
1. Section 1.
I think the main problem with 3DES is not that it is significantly slower
than AES, but that it has blocksize of 64 bits, that is considered
loo small for high-speed networks, when the possibility of birthday
attack
leads to necessity to frequently rekey.
It’s hard to make that case. The blocksize is 64 bits. So it’s prudent to
not use more than, say, a billion blocks.
A billion blocks is 64 Gb. There are very few real tunnels that run that
kind of throughput in under a minute.
OTOH it’s no problem at all to run a CreateChildSA every minute, or even
every five seconds.
So I think there are very few cases that *can’t* use 3DES.
Well, I'm not a cryptographer, but I've heard several times that
the real problem of 3DES is its short block. And the attacker could
precalculate large number of keys, in which case a billion blocks
would not be prudent, the safe number could be a million blocks,
that is too small even for 1Gb networks. Of course it is possible to rekey
every 5 seconds, but it would consume more resourses.
Eventually all those frequent rekeys would lead to decreased performance,
so your initial idea is correct :-)
Yoav
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
