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

From: Mohit Sethi M <[email-masked]>
Date: Sat, 20 Mar 2021 09:11:56 +0000

I am now preparing the shepherd writeup for draft-ietf-lwig-minimal-esp. 
I wanted to clarify and double check a few things:

- If the SPI is not random and is chosen by some application specific 
method -> it can reveal the application using ESP.

- I assume a resource-constrained device would not have many inbound 
connections. Would it make sense to generate a byte of randomness 
instead of entire 32-bit SPI? At least some APIs allow asking for a byte 
of randomness (randomByte()). This is assuming an upper limit on the 
number of inbound connections.

- When sequence numbers are time -> won't it reveal the time at which 
the packet was sent.

- Are we comfortable with the recommendation: 'A node MAY drop 
anti-replay protection provided by IPsec, and instead implement its own 
internal mechanism.'? What might this internal mechanism look like?

A few typos:

-----

Section 3:

Please expand SAD on first usage.

Section 4:

Typo: In a constrainted environment -> In a constrained environment

I looked at old RFCs and they seem to use both crypto-suite and 
cryptosuite. I have a preference for the later. Perhaps we can remove 
the hyphen.

-----

--Mohit

---

From: Daniel Migault <[email-masked]>
Date: Sun, 21 Mar 2021 22:57:39 -0400

Hi Mohit,

Thanks for the review. Please find inline my responses. I have included
your comments as well as additional nits in [1]. As soon as we believe the
version addresses your concerns a new version will be  published.

Yours,
Daniel

[1]
https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/47f1351b1928ba687af18e75e253e98720448e8e

> method -> it can reveal the application using ESP.
<mglt>
It is correct that the use of non random SPI may have some privacy impacts
and one of these impacts is that in some cases, a SPI may be used to track
an application. Note that our intention was to make it clear that when SPI
are non randomly generated, there are some privacy implications to consider
as well as that randomly generated SPI is preferred.

In general an application rarely selects the SPI value to be used. Instead,
the system is rather in charge of applying the security policies and
selects the SPI according to its implementation. Suppose a system is
running X applications and uses Y > X SPI that are not randomly generated
out of the 2**32 possible values. The X applications may be tunneled over
one security association. In that case, the traffic of a specific
application X0 will not be identified from the traffic of the other
applications. So in order to identify one application with an SPI value,
the security association needs to be set for that application specifically.
This may happen in some cases where the device is only running one
application and with a very limited number of SPI. In that case, the
distribution of SPI may have some values that are over-represented.

Note that the draft defined one (common way) to generate the SPI value that
is using a random generator to generate this SPI value. All other means
fall into the category of using deterministic functions. This does not
necessarily mean that a fix of predefined SPI will necessarily be used.
This includes for example the fact that only 2**16 or 2**24 values may be
candidates. The case where one device has a very limited number of SPI is
quite extreme. In any case, it should be estimated how much the SPI leaks
more information than the IP destination and the use of IPsec as well as
the pattern associated with the traffic.
Typically a destination to www.mytemperature.com every 5 minutes with a
fixed size is likely to reveal the presence of a temperature sensor,
independently of the SPI value.

As a conclusion, I am inclined to say, there are some cases when using
nonrandomly generated  SPI over 32 bytes may reveal the presence of a given
application. However, when this occurs, other conditions need to be met. It
seems to me the document mentions clearly that privacy implication needs to
be considered when these alternative methods are considered. If there is
anything that appears not to be clear, I am happy to clarify it.
</mglt>

> number of inbound connections.

<mglt>
The text opposes the 32 bit random SPI versus other ways to generate the
SPI. The alternative you propose falls into that category. It seems to me
that the confusion may come from discussions where we discussed the use of
a fixed small number of SPIs. This specific case has been generalized to
any subset of the 2**32 possible SPIs. I mention the text below from the
current draft that I think should address your concern, but I am fine
making it clearer.

"""
However, for some constrained nodes, generating and handling 32 bit random
SPI may
consume too much resource, in which case SPI can be generated using
predictable functions or end up in a using a subset of the possible values
for SPI.
In fact, the SPI does not necessarily need to be randomly generated.
A node provisioned with keys by a third party - e.g. that does not generate
them - and that uses a transform that does not need random data may not
have such random generators.
However, non random SPI and restricting their possible values MAY lead to
privacy and
security concerns.
As a result, this alternative should be considered
for devices that would be strongly impacted by the generation of a
random SPI and after understanding the privacy and security impact of
generating non random SPI.
"""
</mglt>

> <mglt>
First the use of time is primarily driven to have a always increasing
function, more than the value of the time itself. This could be used with a
clock that is 2 years back in the past or in the future. It is correct that
a few packet analysis may reveal how synchronized the clock of the device
is.
Regarding the time the packet has been sent, it seems to me this is
relatively close to the time the  time is captured, but maybe I am missing
how this could be used or any specific cases where delay tolerant networks
are involved. So I am inclined to say that yes this may leak some
information, but this information may already be leaked.

</mglt>

> <mglt>
Enabling anti reply protection is no mandatory, so that is the default.
RFC4303 mentions:

"""
The field is mandatory and MUST always be present even if the receiver does
not elect to enable the anti-replay service for a specific SA.
"""

Some mechanisms that come to my mind are implementations that receive
packets in a very deterministic manner. Note that the document recommends
to enable anti-replay.
</mglt>

> Please expand SAD on first usage.
<mglt>
fixed. Thanks for raising that issue.
</mglt>

> <mglt>
fixed. I also check there are no other occurrence and it seemed that was
the only occurrence.
</mglt>

> <mglt>
I have removed the occurrences I found of crypt-suite and replaced them by
cryptosuite.
</mglt>

> -----
>
> --Mohit
>
>
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>

-- 
Daniel Migault
Ericsson

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Mar 2021 00:12:35 -0400 (EDT)

On Sun, 21 Mar 2021, Daniel Migault wrote:

(replying to some issues here, but also added a full review of the document)

Side note: I am bit confused why this document would not be a document
from the IPsecME WG ? I know we talked about this before? Did we decide
against adoption at IPsecME ? Can the authors, WG chairs of IPsecME or
the responsible AD shed some light on the history here?

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?

> [1] https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/47f1351b1928ba687af18e75e253e98720448e8e
> On Sat, Mar 20, 2021 at 5:12 AM Mohit Sethi M <mohit.m.sethi=[email-masked]> wrote:
> It is correct that the use of non random SPI may have some privacy impacts and one of these impacts is that in some cases, a SPI may be used to track an application. Note that our intention was to make it
> clear that when SPI are non randomly generated, there are some privacy implications to consider as well as that randomly generated SPI is preferred. 

At the time I also mentioned one attack against IKE that was twarted by
having 4 random bytes as SPI. It remains dangerous to change this
property of ESP, and I recommended to not do that.

https://access.redhat.com/blogs/product-security/posts/sloth

But it seems that although my comments caused the draft to be modified,
it still allows non-random SPIs:

    However, for some constrained nodes, generating and handling 32 bit
    random SPI may consume too much resource, in which case SPI can be
    generated using predictable functions or end up in a using a subset
    of the possible values for SPI.  In fact, the SPI does not
    necessarily need to be randomly generated.  A node provisioned with
    keys by a third party - e.g. that does not generate them - and that
    uses a transform that does not needs random data may not have such
    random generators.  However, nonrandom SPI and restricting their
    possible values MAY lead to privacy and security concerns.  As a
    result, this alternative should be considered for devices that would
    be strongly impacted by the generation of a random SPI and after
    understanding the privacy and security impact of generating nonrandom
    SPI.

So I feel I raised a security issue, and the text just copied my concern
but still basically states implementations MAY do this. I believe this
is wrong.

> Note that the draft defined one (common way) to generate the SPI value that is using a random generator to generate this SPI value. All other means fall into the category of using deterministic functions.
> This does not necessarily mean that a fix of predefined SPI will necessarily be used. This includes for example the fact that only 2**16 or 2**24 values may be candidates. The case where one device has a
> very limited number of SPI is quite extreme. In any case, it should be estimated how much the SPI leaks more information than the IP destination and the use of IPsec as well as the pattern associated with
> the traffic.

I'm not concerned about privacy. As you stated, it is usually pretty
clear what an IoT device is based on where it connects to. I am far
more concerned about security.

> However, for some constrained nodes, generating and handling 32 bit random SPI may
> predictable functions or end up in a using a subset of the possible values for SPI.

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.

What about IVs ? If you cannot generate 4 bytes of random, how it is
going to generate the IVs required for ESP?

> In fact, the SPI does not necessarily need to be randomly generated.

Yes it is does, see the above link on an attack against IKE where the
randomized SPI made offline attacks impossible and online attacks
impractical.

> A node provisioned with keys by a third party - e.g. that does not generate them - and that uses a transform that does not need random data may not have such random generators.

There is a strong move to AEADs, and it would be foolish to limit IoT to
things like AES-CBC because of the IV generation.

> First the use of time is primarily driven to have a always increasing function, more than the value of the time itself. This could be used with a clock that is 2 years back in the past or in the future. It
> is correct that a few packet analysis may reveal how synchronized the clock of the device is.
> Regarding the time the packet has been sent, it seems to me this is relatively close to the time the  time is captured, but maybe I am missing how this could be used or any specific cases where delay
> tolerant networks are involved. So I am inclined to say that yes this may leak some information, but this information may already be leaked. 
>       
> </mglt> 

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).

>       internal mechanism.'? What might this internal mechanism look like?

Again, I do not think that we should write RFCs where to disable
security meassures because the device is too constrained. If that is
the case, perhaps IPsec is not the protocol that should be used? Yes,
we can use IPsec without replay protection, but it is unwise to do so.
Handwaving it to be the implementors or application's problem is a bit
dangerous (though not as dangerous as the SPI case above)

Padding I am less concerned about. Often it is not needed, and TFC is
indeed not used a lot - mostly I think because it really only makes
sense to use TFC based on MTU size, but that in itself will cause
more MTU related issues. And an IoT device is likely to send a fixed
format packet anyway with minimal or no change in packet length, in
which case all packets will be the same length. It could create real
security concerns though, if one could deduce a password length or
something based on the type of IoT device and its packet length.

 	For interoperability, it is RECOMMENDED a minimal ESP
 	implementation discards dummy packets.

I'm not sure what this means. What else would one do with a dummy
packet? Regardless, I don't know of implementations that currently
support sending dummy packets.

I'm a little confused what Section 7 is saying? What does the
implementer need to take in from reading this ?

 	In the latter case, authenticated encryption must always be considered [RFC8221].

I'm unsure what this means? Do you mean AEAD? Or are you refering to the
obsolete encryption without _any_ authentication (eg ESP without
authentication _and_ without AH ) ? Regardless of that "must always be
considered" is basically saying nothing. It is not strong enough.
Compare this to:

https://datatracker.ietf.org/doc/html/rfc8221#section-4

where it clearly states MUST NOT. So your text is is basically negating
that MUST NOT to "consider".

 	When the key is likely to be re-used
        across reboots, it is RECOMMENDED to consider transforms that are
        nonce misuse resistant such as AES-GCM-SIV

But there is no AES-GCM-SIV IKE or ESP algorithm, so you cannot
recommend that. The only thing you can recommend is AES-CBC, and as I
said before, recommending non-AEAD over AEAD is not something I think
the IETF should do.

I cannot parse this sentence:

 	Note that it
 	is not because an encryption algorithm transform is widely
 	deployed that is secured.

I also see some promotion of AES-CTR, which I'm a little uncomfortable
with.

The security considerations section does not list the issue I've raised
here. For AEAD it states that "mechanisms MUST be in place" to prevent
nonce re-use, but the document doesn't really give guidance. In fact,
if anything it is saying there there is no way to carry state across
reboots for that and that keys might be somehow hardcoded and re-used?
So I would like to ask again, what concrete thing should an implementer
take from this section, eg when it is implementing AES-GCM ?

After lots of talk that generating 4 random bytes for the SPI might be
too hard, the Security Considerations lists:

 	When a node generates its key or when random value such as nonces are
 	generated, the random generation MUST follow [RFC4086].  In addition
 	[SP-800-90A-Rev-1] provides appropriated guidance to build random
 	generators based on deterministic random functions.

If you can do that, you can do 4 bytes of random SPI. So these two items
are contradicting each other. Either you can easilly generate random
SPIs and we should keep them at 4 bytes, OR we simply don't have the
resources for RFC4086 and SP-800-90A-Rev-1 based random number
generates. I mean, I can't see them doing a continious self test for
random required by FIPS if you can't even generate 4 bytes of random
SPI.

In conclusion, I think this document is not helpful to implementers. It
is very wordy but lacks clear advise to implementors and while it raises
security issues for those implementers, it does not actually present
solutions for them.

Paul

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 22 Mar 2021 13:14:11 +0000

Hi Paul,

Adding Ben (IPsecME AD) and Erik (LWIG AD) to the CC list for an early heads up.

Thanks for reviewing the document. I'll let the authors provide answers to your review.

On the procedural side of things: this document is within the LWIG charter (https://datatracker.ietf.org/wg/lwig/charter/) and follows the path taken by Minimal IKEv2 which was also completed in LWIG as RFC 7815 (https://datatracker.ietf.org/doc/rfc7815/).

During the call for adoption, there was a general consensus to proceed in LWIG while keeping close contacts with IPsecME (as well as an agreement to issue a joint last call). Tero (https://mailarchive.ietf.org/arch/msg/lwip/Shf2oUKvtIsb0uzY2zRwuBurm58/), Valery (https://mailarchive.ietf.org/arch/msg/lwip/p1i4hZBjn7PD3ksS9kh8C0ouUOU/) and Scott (https://mailarchive.ietf.org/arch/msg/lwip/dF3eZXG8GTV-o7aH4BnFk2zlR6c/) for example provided reviews of the draft.

I think your comments during the adoption (https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) did not argue moving this draft to IPsecME (unless I missed something):

If the document is defining a minimum/battery optimized ESP
configuartion, I have no problems with it and I will review further
text and welcome adoption. If it makes changes to the ESP protocol,
then I think there should be more discussion before adoption.

Paul

That being said, I am not fundamentally opposed to moving this document to IPsecME. However, it is important to consider that the document has already had a relatively long lifecycle in LWIG.

--Mohit

On 3/22/21 6:12 AM, Paul Wouters wrote:
On Sun, 21 Mar 2021, Daniel Migault wrote:

[1] https://protect2.fireeye.com/v1/url?k=267ff37b-79e4ca56-267fb3e0-8692dc8284cb-4b11e1d62003bf58&q=1&e=de278ec7-abe4-4a5c-bad8-76ad8f57cf87&u=https%3A%2F%2Fgithub.com%2Fmglt%2Fdraft-mglt-lwig-minimal-esp%2Fcommit%2F47f1351b1928ba687af18e75e253e98720448e8e
On Sat, Mar 20, 2021 at 5:12 AM Mohit Sethi M <mohit.m.sethi=[email-masked]><mailto:mohit.m.sethi=[email-masked]> wrote:
      I am now preparing the shepherd writeup for draft-ietf-lwig-minimal-esp.
      I wanted to clarify and double check a few things:

<mglt>

<mglt>

</mglt>

    Note that it

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Mar 2021 10:03:25 -0400 (EDT)

On Mon, 22 Mar 2021, Mohit Sethi M wrote:

> On the procedural side of things: this document is within the LWIG charter (https://datatracker.ietf.org/wg/lwig/charter/) and follows the path taken by Minimal IKEv2 which was also completed in LWIG as RFC
> 7815 (https://datatracker.ietf.org/doc/rfc7815/).
> 
> During the call for adoption, there was a general consensus to proceed in LWIG while keeping close contacts with IPsecME (as well as an agreement to issue a joint last call). Tero
> (https://mailarchive.ietf.org/arch/msg/lwip/Shf2oUKvtIsb0uzY2zRwuBurm58/), Valery (https://mailarchive.ietf.org/arch/msg/lwip/p1i4hZBjn7PD3ksS9kh8C0ouUOU/) and Scott
> (https://mailarchive.ietf.org/arch/msg/lwip/dF3eZXG8GTV-o7aH4BnFk2zlR6c/) for example provided reviews of the draft.

Thanks for the write up here.

> then I think there should be more discussion before adoption.

I said that, but I think I am seeing changes to the ESP algorithm that
basically constitute a change to the ESP protocol. Furthermore, a bunch
of advise negating the advise in RFC 8223. And I still haven't heard
a justfication of some issues I raised either. Such as the doing a
full IKE exchange yet not being able to generate 4 bytes of random?

> That being said, I am not fundamentally opposed to moving this document to IPsecME. However, it is important to consider that the document has already had a relatively long lifecycle in LWIG.

After you references I had given feedback, I went back and read that
message. I totally forgot I did that two years ago. But all the issues
I raised back then are still there unresolved.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Mar 2021 17:07:17 +0200

> 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.

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. 

> 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. Requiring SPIs to be random
would be a change from RFC4303, and as such cannot be done in this
document.

For example RFC4301 defines SPI as follows in its Appendix A:
Glossary:

----------------------------------------------------------------------
   Security Parameters Index (SPI)
      An arbitrary 32-bit value that is used by a receiver to identify
      the SA to which an incoming packet should be bound.  For a unicast
      SA, the SPI can be used by itself to specify an SA, or it may be
      used in conjunction with the IPsec protocol type.  Additional IP
      address information is used to identify multicast SAs.  The SPI is
      carried in AH and ESP protocols to enable the receiving system to
      select the SA under which a received packet will be processed.  An
      SPI has only local significance, as defined by the creator of the
      SA (usually the receiver of the packet carrying the SPI); thus an
      SPI is generally viewed as an opaque bit string.  However, the
      creator of an SA may choose to interpret the bits in an SPI to
      facilitate local processing.
----------------------------------------------------------------------

>From the last sentence it is clear that SPI can also be non-random.
You can for example take last 8 bits of the SPI and use that as CPU
identifier, and use next 16-bits before that as index to the SPI table
on that CPU specific SPI table, and use 0xff as first 8-bits just so
you never end up having any reserved numbers for your SPI, i.e., have
SPI as 0xffiiiicc, where iiii is index and cc is cpu id. 

> but still basically states implementations MAY do this. I believe this

But wasn't that attack you referenced, talking about IKE SPIs, not ESP
SPIs? At least that is what I remember about that attack...

Also even IKE SPIs are not required to be random, they are just
required to be unique and non-zero.

> 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.

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.

> going to generate the IVs required for ESP?

Implicit Initialization Vector (IV) for Counter-Based Ciphers in
Encapsulating Security Payload (ESP), RFC 8750,

> randomized SPI made offline attacks impossible and online attacks

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.

> that specified re-using the SN for one of these for other saves you

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
writing to flash is not that fast operation than reading from there.
Note, that lots of these IoT devices wake up, do something, send few
packets, and then go back to sleep. They do have separete hardware
that allows them to wake up after certain timeout, and most likely
also timers that start running when the device was booted up, so they
might have concept of time with certain granularity. They might NOT
have real time clocks or any information how their internal clock
relates to real world clock, and their internal clocks/timers might
not be very accurate, but they should be enough to know that each time
they wake up their time is greater than what it was last time they
woke up. 

> dangerous (though not as dangerous as the SPI case above)

If you want to change this we need to revise RFC4303 and RFC4301.
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.

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.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Mar 2021 12:45:40 -0400 (EDT)

> 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.

> 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.

> 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.

> SPIs? At least that is what I remember about that attack...

Yes, that is correct.

> required to be unique and non-zero.

Perhaps we should update IKEv2 to SHOULD make them random :)

> 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.

> 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.

> random. Currently it does not need to be random, just unique from the

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.

> 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.

> across sleeps, i.e., written to the flash memory.

Again, please add this to the draft.

> 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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 22 Mar 2021 12:47:50 -0400

Hi Paul,

A large part of your comments result from a confusion between the use of
SPI in IKE and ESP. This discussion  has already been set in [1]. Other
comments currently led to two minor updates in the document that have been
published here [2]. So far I believe your concerns have been addressed
unless I am misunderstood them.  Please find my responses in line.

Yours,
Daniel

[1] https://mailarchive.ietf.org/arch/msg/lwip/ygw567rdae2LLXoWTbdbXMejowI/
[2]
https://github.com/mglt/draft-mglt-lwig-minimal-esp/blob/master/draft-ietf-lwig-minimal-esp.xml

> the responsible AD shed some light on the history here?
The document minimal esp complements minimal IKEv2 RFC 7815 that was
adopted in LWIG and the goal of the document seems in scope with LWIG, that
is building minimal interoperable IP capable devices for the most
constrained environment.  As the matter (ESP) might involve the IPsec
community we always cced the ipsecme as well as by making presentations
during ipsecme sessions.
Maybe you could clarify what in particular you find confusing.
</mglt>

> 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.

 <mglt>
The scope of the document is to provide guidance for implementers on
minimal implementations while remaining interoperable. The techniques an
implementer will choose depend on its constraints and environment and there
is not an intention to favor one technique over the others.
This document and describes how an implementer may achieve a minimal
implementation while remaining interoperable. Decision of what to implement
is let to the implementer.
</mglt>

> As such, I'm not in favour of this
> > It is correct that the use of non random SPI may have some privacy
> impacts and one of these impacts is that in some cases, a SPI may be used
> to track an application. Note that our intention was to make it
> > clear that when SPI are non randomly generated, there are some privacy
> implications to consider as well as that randomly generated SPI is
> preferred.
>

<mglt>
The security concerned you raised is irrelevant here. The SLOTH attack only
concerns SIGMA protocols and ESP does not involve any SIGMA protocols.
This concern has been addressed and you agreed in the following words [1]:
"""

As Tero pointed out to me just now, those were IKE SPI's and not ESP
SPI's to I guess there is no security issue here :)

"""
[1] https://mailarchive.ietf.org/arch/msg/lwip/ygw567rdae2LLXoWTbdbXMejowI/
</mglt>

> > Note that the draft defined one (common way) to generate the SPI value
> that is using a random generator to generate this SPI value. All other
> means fall into the category of using deterministic functions.
> > This does not necessarily mean that a fix of predefined SPI will
> necessarily be used. This includes for example the fact that only 2**16 or
> 2**24 values may be candidates. The case where one device has a
> > very limited number of SPI is quite extreme. In any case, it should be
> estimated how much the SPI leaks more information than the IP destination
> and the use of IPsec as well as the pattern associated with
> > the traffic.
>

> random SPI may

<mglt>
As mentioned earlier ESP does not involve any Diffie Hellman exchange and
requirements related to DH exchange do not apply for ESP. The fact that
IKEv2 requires the generation of random does not require the device to
generate SPI randomly. It seems to me the document is usefull to clarify
such misconceptions.
</mglt>

> going to generate the IVs required for ESP?
IV does not necessarily need to be unpredictable as it depends on the
cipher suite. See RFC 8750 for example.  Note also that randomly generating
does not guarantee that no collision occurs.
</mglt>

> randomized SPI made offline attacks impossible and online attacks
I think this has been clarified earlier that there is a
misunderstanding here.
</mglt>

> > A node provisioned with keys by a third party - e.g. that does not
> generate them - and that uses a transform that does not need random data
> may not have such random generators.
>

<mglt>
I am reading this comment as advocating that IVs does not need to be
randomly generated, which seems to me to contradict the previous concern.
Unless I am missing something I agree that random IVs are far from being
necessary in general and that  RFC 8750 provides good examples.
</mglt>

> clock that is 2 years back in the past or in the future. It
> how this could be used or any specific cases where delay
> > tolerant networks are involved. So I am inclined to say that yes this
> may leak some information, but this information may already be leaked.
> >
> > </mglt>
>

<mglt>
I think I am a bit confused about what is the concern related to SN. Your
previous concern was to have random SPIs and random IVs, I do not clearly
how this could concern SN, nor how SN and AEAD are related. Maybe you could
clarify the issue related to AEAD and SN.
</mglt>

> dangerous (though not as dangerous as the SPI case above)
We basically restate the standard ESP and we have no intention to update
ESP. As explained before the dangerosity of non random SPI is a
misconception and does not have any security issues. I suppose the
recommendation is fine then.
</mglt>

> support sending dummy packets.
<mglt>
A dummy packet is indicated by a Next Header value set to 59. The intention
is to prevent these packet to be moved to upper layers and instead
explicitly been discarded. I agree that we may replace the RECOMMEND by
MUST to follow RFC4301. I think the comment was also raised by Valery.
RFC4301 mentions a transmitter MUST be able to generate dummy packets but
does not mandate to generate this packets.
</mglt>

> that MUST NOT to "consider".
I am a bit confused by the comment. The text we are refering is in section
8 and mentionned below:

"""
  1.  Security: Security is the criteria that should be considered

      first for the selection of encryption algorithm transform.  The

      security of encryption algorithm transforms is expected to evolve

      over time, and it is of primary importance to follow up-to-date

      security guidance and recommendations.  The chosen encryption

      algorithm transforms MUST NOT be known vulnerable or weak (see

      [RFC8221] for outdated ciphers).  ESP can be used to authenticate

      only or to encrypt the communication.  In the latter case,

      authenticated encryption must always be considered [RFC8221].

"""

It seems to me that we mandate to follow cryptographic recommendations of
RFC8221 and I do not see how this is weakened or contradicting RFC8221.
Would the "MUST always be considered [RFC8221]". address your concerned. I
have updated the text accordingly.

</mglt>

> said before, recommending non-AEAD over AEAD is not something I think
Again the document is on ESP not IKE. That AES-GCM-SIV is not defined for
IKEv2 does not prevent it to be used for ESP. That said, I agree the
negotiation might be harder. It think the recommendation holds that these
suites are available or not. Hopefully in the future these suites may be
defined.
</mglt>

>         deployed that is secured.
good catch: the text should be
Note that it
        is not because an encryption algorithm transform is widely
        deployed that it is secured.

This has been changed.
</mglt>

> take from this section, eg when it is implementing AES-GCM ?
If no mechanism cannot be found, I am reading the text as considering
looking at ciphersuites that address this problem. I agree that might be
good to provide some details, but I guess these techniques would be very
much ciphersuite dependent. I am wondering if there are any mechanism you
have in mind you woudl like to be mentioned or a reference you would like
to add ?
</mglt>

> random required by FIPS if you can't even generate 4 bytes of random
I think this non issue has already covered.
</mglt>

-- 
Daniel Migault
Ericsson

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Mar 2021 20:13:32 +0200

> with the document. I think the list of clarifications we now have is:

I think your list of things to add is mostly ok.

Note, that on some enviroments creating random numbers is possible,
but it takes time, and power to do so. For example it might be that
hardware random number generator is normally powered off, and is only
powered on during the IKE SA creation phase, and can only create
random numbers at very limited speed. It also might require some time
do self tests, calibration etc before it can be used, so using it per
packet might not be usable, while using it for generating randomness
during the initial phase is no problem.

Perhaps all this should be collected to one new section of the draft,
explaining that you do need proper randomness for Diffie-Hellman etc,
but for ESP you might not need proper random number generators.

> - A clear section on why AES-CBC/3DES-CBC cannot be used due to IV

That is not true. CBC mode requires IVs to be random and
unpredictable, but they do not really be true random, it is enough to
use pseudo random number generators for that. One way to get that is
to use fixed secret key (only known to the device, and no, do not use
key derived from the serial number or mac of the device or similar)
and encrypt the incrementing time with such key.

That should provide proper random IVs than can be used in CBC mode,
and which are unpredictable to everybody who does not know the key
used to generate them.

>    algorithms" to avoid TLS confusion

IKEv2 RFC7296 uses cryptograhic suites. RFC4303 or RFC4301 does not
use term suite at all. I would prefer keeping that same term than what
IKEv2 uses.

>    standarized yet". This draft has been abandoned in 13 years ago.

There has been some discussion every now and then to revive that
draft. There is some good properties in that especially for IoT
environments, as it does not send the extra inner IP header, when that
IP header can be constructed from the SAD.

Anyways that draft is clearly something that is not in scope for lwig,
but falls in the IPsecME scope, so removing that text now is probably
correct. 
-- 
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Mon, 22 Mar 2021 16:47:41 -0400

Hi,

To complement my previous response, I have added some text provided by Tero
to clarify the generation of SN from the time. We also added some
explanation around anti replay as well as some more context on the various
constraints different devices may have. We also add some clarification
about what dummy packet are as it seemed the reference to RFC4301 and
section was not sufficient.
On the other hand, I do not believe that is necessary to duplicate the
discussion around the choice of a specific transform and this discussion
should happen in the ESP cryptographic recommendations RFC8221. This also
avoids the document to be updated as crypto evolves and new transforms are
introduced.

The current version is available here:
https://github.com/mglt/draft-mglt-lwig-minimal-esp/blob/master/draft-ietf-lwig-minimal-esp.xml

Please find my response inline.

Yours,
Daniel

On Mon, Mar 22, 2021 at 12:45 PM Paul Wouters <[email-masked]> wrote:

> For AES-CBC, RFC 3602 states:
> https://tools.ietf.org/html/rfc3602#section-3
>

<mglt>
The text seems as it is sufficient to address your concern:
In fact, the SPI does not necessarily need to be randomly generated.

When a constrained node limits the number of possible SPIs this limit
should both consider the number of
inbound SAs - possibly per IP addresses - as well as the ability for the
node to rekey.
SPI can typically be used to proceed to clean key update and the SPI value
may be used to indicate which key
is being used. This can typically be implemented by a SPI being encoded
with the Security Association Databas
e (SAD) entry on a subset of bytes (for example 3 bytes), while the
remaining byte is left to indicate the re
key index.
</mglt>

>    storing an absolute counter on  flash is bad, and timing can be used
<mglt>
The text already mentions RFC8750
</mglt>

> - Clarify why sequence numbers cannot be sequential - flash writes are
<mglt>
Text proposed by Tero has been included.
</mglt>

> - A clear section on why AES-CBC/3DES-CBC cannot be used due to IV
<mglt>
The text delegates the crypto recommendations to 8221 which mentions 3DES
has should not and mentions AES_CBC to be replaced. I do not think that the
discussion should be duplicated here. In addition the text mentions the
following recommendations:
 - Use of counter-based ciphers without fixed block length (e.g. AES-CTR,
or ChaCha20-Poly1305).
 - Use of ciphers recommended for IoT *[*RFC8221].
</mglt>

>    their IV-less names from RFC 8750.
<mglt>
The text mentions as a second recommendation:
- Use of ciphers with capability of using implicit IVs *[*RFC8750].
</mglt>

>    clarify "once/if available for ESP".
<mglt>
ESP does not define transform these are defined by IKE. AES-GCM-SIV is the
algorithm not the transform. See my response in my previous email.
</mglt>

> - call "ChaCha20-Poly1305" by its name CHACHA20_POLY1305 (and maybe also
<mglt>
The ChaCha20-Poly1305 is mentioned for its cryptography properties not as a
transform. These remain independent of the multiple associated transform
using it. Again the choice of the specific transform is delegated to
RFC8221.
</mglt>

>    the title of the section too.
 <mglt>
I understand the problem was a mis interpretation of the dummy packet which
has been clarified with the following text:
"""
 i.e. packets with the Next Header with a value 59 meaning "no next
header".
"""
</mglt>

>    algorithms" to avoid TLS confusion
<mglt>
I think IKEv2 uses suites or transform.
</mglt>

>    wake/up sleep vs reboot, getrandom limitations)
<mglt>
The text has been updated with :
 As a result, constraint devices are likely to have their own
implementation of ESP optimized and adapted to t
heir specificities such as limiting the number of flash writes (for each
packets or across wake time), handli
ng frequence wake/up sleep while limiting wake time, or reducing the use of
random generation.
</mglt>

>    I don't think with continuous self test, it can be fully FIPS
<mglt>
The reference has been kept as suggested by Scott.
</mglt>

>    to least important? I think so but it does not state this.
<mglt>
I find it difficult to define a universal order.
</mglt>

>    standarized yet". This draft has been abandoned in 13 years ago.
I think it is useful to keep the text mentioning that in some case NH is
used otherwise but we do not have to bother. While not standardized, it is
implemented and used. I agree though it is not essential, but I do not see
it as hurting.
</mglt>

> goal is to keep the changes to a minimum for the draft authors to make
We want to keep the changes minimal also to avoid overwriting text that has
been agreed before.
</mglt>

-- 
Daniel Migault
Ericsson