Re: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00

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) <sfluhrer@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
>