Hi Valery, a few comments inline.
On Tue, Jul 28, 2020 at 11:13:33AM +0300, Valery Smyslov wrote: > Hi, > > a few thoughts about this proposal. .... > > > * 64 bit sequence counters in each header to ease protocol handling and > > allow for > > replay protection in multicast groups > > This would simplify replay protection logic on receiver, but will waste > 4 bytes on the wire for unicast SAs. We have already the option to send the high sequence number bits when a combined mode algorithm is used. RFC 4303, Section 2.2.1. says: If a combined mode algorithm is employed, the algorithm choice determines whether the high-order ESN bits are transmitted or are included implicitly in the computation. We could just give multicast the same option if it wants to use replay protection. > > * Removing the trailer to ease segment & fragment handling and alignment > > I was told by Linux kernel people that having trailer in ESP is a headache > for them. > However, this simplification has its cost: > > 1. Ciphers that require padding cannot be used. I admit that CBC and the like > are out of fashion today, but I don't know which cipher modes will be in > fashion tomorrow > and what requirement for padding they will have. > 2. No Next Header field eliminates transport mode (BTW, widely used for > multicast!) > and makes it difficult to implement TFC (you can add TFC padding, but > you can't send > dummy packets and you can't use IPTFS) Instead of a trailer, an (optional) encrypted header could be used for transport mode, IPTFS etc. That could be | Pad Length | Next Header | Pad to align payload | > > > * Implicit IVs in spirit of RFC 8750 removing the need for AAD > > I don't consider removing AAD is a benefit, since all the AEAD schemes I'm > aware of > allow to have AAD. On the other hand, implicit IV is only applicable > to some transforms. I'm not only talking about non counter-based AEAD ciphers, > (like CBC), but even for counter-based AEAD a situation is possible when > there is a need > for IV to be somehow structured and not be a plain counter (e.g if you > implement key trees). Right, we should always have the option to include an explicit IV as the IV construction depends on the used algorithm. > > > Further details and benchmark results may be found in a paper preprint [1] > > and a > > presentation [2] we held with at the Linux IPsec Workshop. > > A few more considerations. > > It seems that performance of this proposal depends on ICV size > for the plaintext to be properly aligned. > If ICV is 16 bytes, then plaintext is ideally aligned on 32 bytes, > but if one use 12 byes ICV (e.g. ENCR_AES_GCM_12) > then the plaintext is aligned on 4 bytes, that is even worse > than ESP, where it is for most AEAD transforms aligned on 16 bytes. We could pad a 12 byes ICV up to 16 bytes, but I have to admit that this might not be the best option. > Since this proposal allows only tunnel mode, it will have > larger overhead for small packets. This is partially > compensated by having IV to be implicit... > > And about security. In order to have IV combined with > ESN and sub-windows identifiers this proposal removes secret > salt from the nonce. This may have impact on security. > I'm not a cryptographer, but I believe the impact is not negligible. > On the last CFRG session a draft draft-wood-cfrg-aead-limits was > discussed that calculates limits of data to be safely encrypted > by various AEAD ciphers. The authors claimed that having > secret salt in the nonce increases this limits in case of multi-user > attacks and that the results in the draft are calculated > for this case. If plain AEAD ciphers (with no secret salt) are used > the limits are lower. A secret salt in the nonce would be a new requirement anyway. I've checked RFC 4106 (ESP for GCM) and RFC 7634 (ESP for ChaCha20-Poly1305), both don't require a secret salt. But I'm not sure if the IV construction in this proposal would be always a good choice. As far as I understand, Sender ID is only used with multicast, so will be most likely zero on unicast. Also the replay window ID will have a lot of zero bits on unicast (given that most nodes have much less than 2^16 cpus these days). Steffen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
