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

[Daniel Migault <[e-mail]>]

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

On Mon, Mar 22, 2021 at 12:12 AM Paul Wouters <[e-mail]> wrote:

> 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?
>
> <mglt>
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>

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.

 <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
> 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=
> [e-mail]> wrote:
> >       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.
> >
> > <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.
>
> 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.
>

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

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

>
> What about IVs ? If you cannot generate 4 bytes of random, how it is
> going to generate the IVs required for ESP?
>
> <mglt>
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>

>

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

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

>
> >       - When sequence numbers are time -> won't it reveal the time at
> which
> >       the packet was sent.
> >
> > <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>
>
> 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).
>

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

>
>
> >       - 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?
>
> 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)
>
> <mglt>
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>

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

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


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

> I cannot parse this sentence:
>
>         Note that it
>         is not because an encryption algorithm transform is widely
>         deployed that is secured.
>
> <mglt>
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>

>
> 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 ?
>
>  <mglt>
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>

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.
>
> <mglt>
I think this non issue has already covered.
</mglt>

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


-- 
Daniel Migault
Ericsson