-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/14/2012 07:08 AM, André Becker wrote: > Hi, > > Am 14.03.2012 14:15, schrieb Marc Petit-Huguenin: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 03/14/2012 03:31 AM, André Becker wrote: >>> Hi, >>> >>> Am 14.03.2012 00:11, schrieb Marc Petit-Huguenin: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>> >>>> On 03/13/2012 02:02 PM, André Becker wrote:
[...] >>> Thanks for the pointer. However, the discussion back then did not >>> include the security aspects. I outlined a possible attack on RELOAD >>> using the current ConfigUpdate mechanism in my bachelor thesis which >>> is, unfortunately, written in german. But here a short summary of the >>> attack: >>> >>> An adversary who is part of the overlay can store an old message of a >>> node he wants to attack (called the target node). He now changes the >>> configuration_sequence number (which is not included in the signature) >>> to an old value and sends this message to an arbitrary destination node >>> in the overlay. What does this node do? It first generates an >>> Error_Config_Too_Old which is sent to the adversary (by reversing the >>> via list). The ConfigUpdateReq, however, cannot be sent by reversing >>> the via list, it is a totally new request with new transaction_id. This >>> request is sent to the creator of the message, which is not the >>> adversary, but the the target node. >>> >>> This means the adversary can cause an arbitrary node to send a message >>> of big size, probably RELOADs biggest message to a target node he wants >>> to attack. This node MUST check the message's signature, which is the >>> potentially most expensive operation in RELOAD. Now the adversary can >>> send it's, let's say "forged messages" (old messages with altered >>> configuration_sequence) to a huge number of nodes over routes of >>> different lengths (arranged with appropriate destination lists). These >>> nodes that generate the ConfigUpdateReqs also have different distances >>> to the target node. This means: >>> >>> If correctly timed, the adversary can cause a huge number of messages >>> of big size to arrive at the target node at approximately the same >>> time, which definitely could result in a denial of service. The >>> adversary needs only one single node to form the attack AND he cannot >>> be detected by the attacked peer. >> The configuration_sequence field should probably be part of the >> signature. > I thought about that too, but I think that does not solve the problem. > This would mean that, before a ConfigUpdateReq is generated, the receiving > node had to validate the signature of the request. But: Can or should a > node be able to validate a signature computed with an old configuration > document? I don't think so, as the root certificates are part of the > document. Well, this is not explicitly said in the I-D, but a reasonable way to implement RELOAD is to be sure that any new version of the configuration document always also contains the old root certificate when a new one is distributed. > Also, a possible extension to RELOAD could be to include allowed (or > required) algorithms for signature computation in the configuration > document. This would stress this problem even more. > > This is why I would prefer to keep the configuartion_sequence out of the > signature. If the attack I presented is a serious issue (which I think it > is), the questions is which change would cut deeper: Checking of > configuration_sequence by each peer on the route, or taking > configuration_sequence into the signature. In my implementation, the > latter would cause more work, but I can't speak for other implementations. > - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPYLe+AAoJECnERZXWan7E1XUP/jqq+58xGEVTUXOt5T5Hh4VR U2xZ2m/pFPlk8Sv5mEWLkbSITohMkn8gL+3aViCtSrRqZdAkD65cGLrbd1vGQojL AATT5QM3WCeUtSsC/gXquqJcej5nRweVICs2A0WguzKY7YMKCJz9V17W0TVfRi/P 0+FTZKPy3os1FGGIWweKbWluHzRsvCSM83SXiCk8y0uCZ9ChK0iVECl1OBIy2xIK OSlT8SjKEJZMHdF9EGRGLNrcavkungp6XhwV6/ji5SaBDqHSiM2AJtVtFBrnBQkM V81LoQ4C144c5s82c+ClSKh5sW0CEKu73K28Y8IrUBfISs11oaLO687HbIu1F7S9 SngSeuOvtpi3SLInGPOBhDMwh1mcHIBp2QdbGQb9SZbd+ULNxX+SLpWXWk+Hngw3 i3ZamKiu1/DVn1uJlX2ZvR4ylPDZojGsY63WaCpyH7qAsKsvkuytGweDe0Yzj3U6 qARLW+21/hPmiU/VwcP48R4MprzVqJ+e+OhLFcalwbL0kAK8hPBhqLNOW408tfKP O7HaawKrWaAWvTHjqp/FMdNMG5MZbCJ9dDPvl5jr0ojr8bU6uaGIGMrfjKen1R+/ TZCAuTAnnNrhPcXuECO99WHFj6QCMkxOCBoNcfHE7DWko86Z6t+S70JmbN6A6mGr N3AnsnAAy98IrXPkR9pk =MaE2 -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
