Thanks Scott for the comment. I will address them tomorrow, I am just sharing the review to the lwig list. Yours, Daniel
On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> wrote: > Comments: > > > > - I have issues with the draft’s emphasis on fixed SPI values. One > reason for the SPI value is to handle key updates cleanly; during the > transition, the SPI can be used to indicate whether the packet was > encrypted with the previous set of key or the new ones. As we really don’t > want to discourage rekeying I would suggest that, instead of talking so > much about fixed SPIs, you instead address how to do nonrandom SPIs (for > example, by having the top 3 bytes of the inbound SPI being the SAD entry, > and the lower byte being the rekey index). > - “Values 0-255 SHOULD NOT be used.”; shouldn’t that be MUST NOT? Can > you think of an advantage a device might have for using a SPI in that > region? > > The use of fix SPI MUST NOT be considered as a way to avoid strong random > generators. Such generator will be required in order to provide strong > cryptographic protection”; actually, if the IPsec implementation doesn’t > actually generate its own keys (that is, it relies on an external service > to provide them), and the transform itself doesn’t require random data (CBC > can be implemented securely without one), then the IPsec implementation > doesn’t actually need an CSPRNG. > > - SN based on clocks; one issue that is not addressed is that standard > receivers are tuned for an increment of one-per-packet; if the sender uses > increments significantly larger than that, and packets are reordered, the > receiver is more likely to reject valid packets because they fell outside > the window. > - One issue you do not address (but I believe you should) is the fact > that some cryptographical transforms are more resilient for key reuse (e.g. > because you use a fixed key, and don’t change it after a reboot) than > others. In particular, both GCM and ChaCha20-Poly1305 have real problems > when that happens, and should be avoided. > > > > Typos: > > - a random SPI may consume to much -> too much > - fix SPI -> fixed SPI > - can be alleviate -> can be alleviated > - algorythm -> algorithm > - > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
