Considering that I didn't know what "now" meant and this message didn't have a deadline, I hope my input is considered. I prefer the first option - we need to document the associated threat model with each assumption, but, deployments need to figure out what their threat model is. The one RT resumption mechanism is key for handoff situations and for certain environments, it doesn't allow new attacks that are feasible outside of the IPsec use anyway. If we threw out this model, we will be preventing a whole class of use cases that could otherwise use this resumption mechanism.
Note that for these use cases, it is not much more expensive to just do the DH and use regular IKEv2, instead of using resumption, if the latter also involved as many roundtrips. Thanks, Vidya > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Paul Hoffman > Sent: Wednesday, April 08, 2009 10:56 AM > To: IPsecme WG > Subject: [IPsec] Issue #98: 1 or two round trips for resumption > > Greetings again. Tracker issue #98 is the same as the message that Pasi > sent to the mailing list last month; see <http://www.ietf.org/mail- > archive/web/ipsec/current/msg04050.html>. There is disagreement among > the authors of the session resumption draft how to deal with this > issue. > > One proposal is to add text similar to Pasi's to the document in order > to let implementers understand all the things that they might need to > do to prevent damage from a replay attack. If this is the method > chosen, it should probably be as a section in the main body of the > document, not as a "security consideration" because the issues are more > operational than security. > > A different proposal is to get rid of the one-round-trip mode and have > the protocol always take two round trips. This prevents the attack that > Pasi brings up, at a higher cost for the clients and server. > > If you have a preference between these two proposal, please state it > now. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
