On Mon, 22 Mar 2021, Tero Kivinen wrote:
In general, this draft is very "wordy" because it is trying to steer
itself around a lot of problems, without making firm decisions. But
the point of an RFC is that it should make clear decisions that
implementers can adopt clearly. As such, I'm not in favour of this
draft. I believe I stated this before?
This draft does not change anything in the ESP, it only gives
guidelines to the lightweight implementations so they can more easily
understand what kind of optimizations are allowed by standard ESP and
what benefits or concerns there might be from selecting them.
I find the guidelines it gives unclear. This email has helped a lot and
I would really like to see some of this text included in the draft.
Because it does not change ESP, it is not really IPsecME WG job. It is
similar than RFC7815 Minimal IKEv2 Initiator Implementation document,
which was also published from the LWIG WG and not from the IPsecME WG.
Thanks for the process explanation. I'm okay continuing it this way.
But it seems that although my comments caused the draft to be modified,
it still allows non-random SPIs:
This document cannot mandate that SPIs need to be random, as no such
requirement is in the standard ESP RFC.
Interesting, I did not realise that. The draft could be clarified to
simply state like, something like:
RFC4303 states tat SPI's must be unique, but do not require to
be random. Most implementations do use random SPIs but this
might not be possible for constrained devices. These devices
MAY use non-random SPIs.
But wasn't that attack you referenced, talking about IKE SPIs, not ESP
SPIs? At least that is what I remember about that attack...
Yes, that is correct.
Also even IKE SPIs are not required to be random, they are just
required to be unique and non-zero.
Perhaps we should update IKEv2 to SHOULD make them random :)
If such a device cannot generate 4 random bytes, how is it performing a
DiffieHellman key exchange? Or is it presumed that IKE is done
elsewhere? In which case "elsewhere" can generate 4 random bytes.
I do not think SPI issue is about generating it, but using it for each
incoming packet. If device has only support for 4 incoming SPIs, it
might just create SPIs using format 0x8000000x, where x is the index
in its SAD. Then getting address of SAD structure in memory could
simply be (SPI << (sad_table_shift)) + sad_table_start_address after
checking that (spi & 0xfffffffc) == 0x80000000.
Again the draft should be making this distinction clear. To me it seems
to suggest that creating them randmonly was the problem being addressed.
Generation of the SPI is single operation, and as such not an issue.
Mapping SPI -> SAD entry must be done for every incoming packet, and
saving cycles from there might make difference.
What about IVs ? If you cannot generate 4 bytes of random, how it is
going to generate the IVs required for ESP?
Implicit Initialization Vector (IV) for Counter-Based Ciphers in
Encapsulating Security Payload (ESP), RFC 8750,
That is only for the IV of AEAD algorithms. But the draft wiggles between
discourages these because if you re-use the key along reboots without keeping
state, you would re-use the same IV (counter). Later on in the document,
and along with your explanation in this email, I understand that the
time based counter addresses this. I think it should be made much more
explicitly clear so that implementers know this.
For AES-CBC, RFC 3602 states: https://tools.ietf.org/html/rfc3602#section-3
The IV field MUST be the same size as the block size of the cipher
algorithm being used. The IV MUST be chosen at random, and MUST be
unpredictable.
So the draft basically states that for systems not able to generate a
random bytes, that it cannot use AES-CBC. It should state this
explictly.
IKE SPI or ESP SPI? My understanding those attacks were against IKE,
not against ESP.
And if what you are saying is true, then we as an IPsecME needs to
start making modification to the ESP to actually require the SPI to be
random. Currently it does not need to be random, just unique from the
local point of view.
Based on the attack, this would only be needed for IKE, not ESP. But for
implementations this draft targets, that would be a similar
insurmountable problem? Again, it would be useful to explain why pure
random is harder to do then using something time based.
The secion on Sequence Numbers concerns me too, and for the same reasons
as above. If you cannot keep a sequence number as state, you cannot do
any AEAD encryption. I believe it is a bad idea to still write
specifications today that require non-AEAD algorithms. Once you can do
it for AEAD, then you can do it for SN too (and using the other draft
that specified re-using the SN for one of these for other saves you
those bytes once).
You can use AEAD encryption with sequence numbers generated by time
without any problems. I would expect most of the IoT devices will use
AEAD ciphers, as for example IEEE Std 802.15.4 is only defined to
support AEAD ciphers, and the only one currently defined there is
AES-CCM, and that AEAD AES-CCM is used with timebased nonces when used
with TSCH currently.
The problem with regular sequence numbers is that you need to store
them to stable storage every time you go sleep. Storing the SA
information (keys, SPIs etc) to the flash once after the creation of
the SA can be done, as that is just one flash write per SA creation.
Syncing sequence number to flash after every packet would quickly wear
out the flash, and most likely also slow down the system greatly, as
That's a great explanation of how AEAD can work and the difference
between storing sequence numbers and storing crypto keys. It should be
in the draft too.
Replay protection has always been optional for the receiver. There are
lots of ways to do things in a way where you do NOT need replay
protection on the ESP layer.
The problem with replay protection is again that it needs to be stored
across sleeps, i.e., written to the flash memory.
Again, please add this to the draft.
If the IoT device you are talking about is for example temperature
sensor and the protocol is such that sensor wakes up every 60 seconds,
sends sensor measurement over ESP, and waits for ACK back from the
controller, and after receiving the ACK it goes back to sleep, there
is no need to have replay protection on the sensor end. Yes, attacker
who can block the connection between the sensor and controller, can
replay ACKs and cause the sensor to be happy and not notice that it
has lost connection to the controller, but on the other hand even if
the sensor would notice that it has lost the connection to controller,
there is nothing it can do, as there is no way of indicating that
information other than over the radio and attacker is already blocking
that. Temperature sensors usually do not have displays or keyboards,
and even when there might be LEDs on the board, they do not help much
when the sensor is inside the building wall.
Again, great addition for anyone reading the draft why it is okay.
Reading back now, I think with some clarifications added, I am okay
with the document. I think the list of clarifications we now have is:
- clarifying ESP SPI's do not need to be random, with reference to 4304
and explain why random ones take more resources and fixed ones might
be used.
- clarify why counter as entire IV is okay (because AEAD) and why
storing an absolute counter on flash is bad, and timing can be used
instead.
- Clarify why sequence numbers cannot be sequential - flash writes are
bad.
- A clear section on why AES-CBC/3DES-CBC cannot be used due to IV
randomness limitations
- clearly recommending an AEAD like AES-CCM or AES-GCM. Consider using
their IV-less names from RFC 8750.
- Remove reference to AES-GCM-SIV which does not exist for ESP, or
clarify "once/if available for ESP".
- call "ChaCha20-Poly1305" by its name CHACHA20_POLY1305 (and maybe also
by its RFC 8750 name)
- clarifying section 6 that this is not about the Next Header (being
removed) but just about not supporting dummy packets. Probably change
the title of the section too.
- change "cryptographic suites" and "crypto-suites" to "cryptographic
algorithms" to avoid TLS confusion
- update the introduction to introduce the constrains (flash writes,
wake/up sleep vs reboot, getrandom limitations)
- figure out what to do with the FIPS reference on randomness (because
I don't think with continuous self test, it can be fully FIPS
compliant?)
- Clarify the list in section 8. Is this ordered from most important
to least important? I think so but it does not state this.
- Remove reference to I-D.nikander-esp-beet-mode, with the text "not
standarized yet". This draft has been abandoned in 13 years ago.
I'm willing to help with text if the authors want, but I think if I did
that, the diff would be quite large as I would be clarifying things be
being more epxlicit and use fewer words. So it might be better if the
goal is to keep the changes to a minimum for the draft authors to make
the changes.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
