Re: [Lwip] [IPsec] draft-ietf-lwig-minimal-esp shepherd writeup

[Paul Wouters <[e-mail]>]

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