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: (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://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=40ericsson....@dmarc.ietf.org><mailto:mohit.m.sethi=40ericsson....@dmarc.ietf.org> 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. 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. 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. - 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). - 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) 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
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
