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

[Michael Rossberg <[e-mail]>]

>> 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 do not have any algorithms that use that feature, and we do not
> have option to negotiate it in IKEv2.
> 
> We could add new value for transform type 5 (Extended Sequence
> Numbers) to say that we use extended sequence number, and that we
> actually transmit the full extended sequence number.

That would already help for the case.

>> We could just give multicast the same option if it wants to use
>> replay protection.
> 
> As others have already pointed out earlier, with multicast the upper
> layer must make care of replays and dropped packets themselves in any
> case, so doing that also on the IPsec level does not really provide
> that much more security. I mean if the multicast protocol run over UDP
> over IPsec simply has internal sequence number inside the UDP, which
> will then be authenticated by the IPsec that should be good enough for
> replay protection.
> 
> There is issue that in that case attacker could do Denial of Service
> attack against the IPsec, by replaying packets, and then the IPsec
> gateway would decrypt and forward them.

Like pointed out in the answer to Valery’s mail. There are possibly more
issues, as attackers are able to generate new traffic, they can use for
cryptanalysis (see
https://www.aircrack-ng.org/doku.php?id=arp-request_reinjection).
Having anti-replay guarantees is just a reliable foundation. IMHO the
case of applications being responsible holds just as well for unicast
applications. TCP takes care of that, still no-one honestly discusses
removing replay checks for high volume unicast SAs.

> When using multicast you already need to use SPI, and destination
> address as your SAD lookup (RFC4303, section 2.1), i.e. use option 2
> there. On the other hand you could use the SPI, destination address,
> and source address to find the replay window and largest sequence
> number used if you want to do anti-replay protection on multicast SAs
> so that each sender has separate replay windows.

This still requires to know all possible senders beforehand. Also the
SAs will still need to agree on an IV subspace and sending an explicit
IV per packet.

>>> 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.
> 
> It is true that they do not need secret salt, but they do have
> unpredictable salt, which is created by the key derivation step. My
> understanding was that this proposal did get rid of that salt too:

Like written already: An unpredictable value of 32bit size is of no real value
from a crypto point of view. One could simply guess the value and have
a realistic chance of being right after a couple of thousand tries. I believe it
is only in the standard, as with 64 bit sequence numbers there where 32 bits
left; needing to be filled.