Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

[Stephen Farrell <[e-mail]>]

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
> 
>