On 07/02/2014 10:26 AM, Miika Komu wrote:
Hi,
On 06/30/2014 08:46 PM, Tom Taylor wrote:
3) Section 5.2.18: given the strict ordering of HIP parameters, the
initial
plaintext for the Encrypted content (type and length of initial
parameter) may be fairly easily guessed. This opens up the minor
possibility of a known plaintext attack. [Comment to be reviewed after
further examination.] [Upon review: I1 packets have fixed type but
variable length due to varying lengths of DH-GROUP-LISTS. The set of
such lengths is limited, however, so it is worth considering whether
known plain-text attacks offer any real threat.]
Discussion: I don't know how/whether to handle this, or whether other
similar vulnerabilities in other security protocols are addressed.
Changes to address this would likely complicate things or increase the
packet sizes.
[PTT] I have to leave it to people more knowledgeable in security to
judge whether this is a realistic attack. One point of approach is to
find out what sample size is needed for known plain-text attacks for
specific algorithms, compare that with the rate at which an attacker
could collect encrypted messages in specific scenarios, and decide
whether there is a real threat. Mitigation presumably might be through
adjustment of the rate of key rollover.
do we actually need the encrypted parameter for something really
critical (i.e. some extensions rely on it)? If not, we could just
remove it. Usually the encrypted parameter just contains the HOST_ID
of the Initiator which does not really offer any real privacy since
the HIT is in plaintext and actually can interfere with middleboxes
(as already mentioned in the draft).
There are other uses for the encrypted parameter. It should not be removed.
If the encrypted parameter is critical, here's a straw-man proposal
that avoids increasing packet size: XOR the contents of the encrypted
parameter by iterating through it block-by-block using the encryption
key. Then, encrypt it with the same key.
Sounds interesting.
If packet size is not a problem, we could include an extra, fixed size
key for XORing within the encrypted parameter. Or perhaps just encrypt
the plaintext twice with the encryption key.
(My solutions are presented in chronologically in the order of my
personal preference)
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
