On 02 Jul 2014, at 17:32, Miika Komu <[email protected]> wrote: > Hi, > > On 07/02/2014 05:26 PM, 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). >> >> 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. >> >> 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) > > on second thought, do we actually have a real problem here? Let us consider: > > * The encryption key is different for each base exchange, so the roll over is > actually occurring every time, so that observing multiple base exchanges does > not benefit the attacker
Just for the sake of completeness: The ENCRYPTED parameter can also be used in other messages such as UPDATE (currently not the case). Still, this is a low volume control channel. > * To derive the encryption key, you need a very expensive brute for search, > and the award is (usually) just the public key of the initiator > * If the parameter contains something else in addition to the public key, the > brute force search is still very expensive (exponential) The award of a known plaintext attack would be the encryption key not just the the content of the ENCRYPTED parameter. HIP_MAC would not be compromised though as it uses its own key. Nevertheless ... > * The default algo (AES) is resistant against linear and differential > cryptanalysis This would also be my conclusion. > So, I am not convinced that the current mechanism should be changed. +1 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
