Re: [IPsec] Teaser for pitch talk at IETF 108

[Steffen Klassert <[e-mail]>]

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