On 04/06/11 21:04, Paul Hoffman wrote: > On Jun 3, 2011, at 7:15 PM, Uma Chunduri wrote: > >> exactly how is MD5 the weakest link here? some particular words about the >> threat model + ability to subvert a running session which ships a few >> megabytes/minute around would be in order here. >> >> [Uma] >> >> 1. Wang, X., H. Yu, "How to break MD5 and other hash >> functions", Proc. IACR Eurocrypt 2005, Denmark >> 2. RFC 4270 > > Wearing my co-author-of-4270 hat, let me state forcefully: invoking RFC 4270 > or *any* current published work on MD5 does not answer the question of how > MD5 is the weakest link here. Those are *unrelated* to an attack on the > integrity of communication in draft-sidr-rpki-rtr. Collision attacks on MD5 > and SHA-1 are, to date, unrelated to preimage attacks, and it is preimage > attacks that you care about.
So I've been thinking a little about this. First, I do not know of any practical md5 preimage attacks so far, however, if we allow tcp-md5 in this spec, we're effectively betting that that will remain the case for a few years at least and that's not a bet with which I'd be happy when we do have stronger options that are already specified. Second, and perhaps more importantly, given that md5 is broken for collisions, there may be other attacks on this protocol using tcp-md5 that are enabled by that fact and that do not require a preimage break for md5. For example, if an attacker generates two colliding values t2 and t2' and gets a value related to t2 injected into the rpki so that at some later point a cache response message will have the value t1|t2|t3, then our (now on-path) attacker sees t1|t2|t3|MD5(t1|t2|t3|secret) and can substitute t2' for t2 and have that work. I'm making many assumptions here about encodings, lengths and the amount of work involved all working out for an attacker who can inject values into the rpki and be on-path, but I think those are not necessarily unreasonable given the rapidssl attack of a few years ago. [1] [1] http://www.win.tue.nl/hashclash/rogue-ca/ So, unless I'm off the mark on this point, (which is quite possible), I think that tcp-md5 is simply unacceptable here. Stephen. > > > On Jun 4, 2011, at 9:38 AM, Stephen Farrell wrote: > >> Trying to catch up with you all here. >> >>> From reading the mail thread it seems to me that: >> >> - tcp-md5 is available but undesirable >> - tcp-ao is desirable but unavailable so far >> - ssh is available and slightly undesirable for >> performance reasons but desirable in >> security terms >> >> That would imply that an answer might be: >> >> MUST implement SSH; SHOULD implement TCP-AO and >> MUST/SHOULD prefer TCP-AO over SSH if both >> available >> >> Would that garner (rough) consensus? > > Another proposal that might be more likely to garner rough consensus would > be: MUST implement TCP-MD5 [RFC2385]; SHOULD implement TCP-AO [RFC5925] (the > official successor to TCP-MD5) as soon as possible; if both parties in the > protocol support TCP-AO, they SHOULD use TCP-AO and SHOULD NOT use TCP-MD5. > After we believe that there is lots of TCP-AO adoption, we revise the > document and remove TCP-MD5 as an option. > >> We really do want to deprecate tcp-md5. > > We already have: RFC 5925 obsoletes RFC 2385. The question is whether we want > to prevent new protocols from using it and instead force them to use > something else that doesn't work as well operationally while TCP-MD5 is still > considered safe. Saying "MUST implement SSH" is tantamount to saying "many > systems will run unprotected", which might be acceptable until TCP-AO is > deployed. However, using TCP-MD5, but only until TCP-AO is deployed, seems > like a better idea. > > --Paul Hoffman > > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
