[Babel-users] [babel] rather than ripemd160...

[Dave Taht]

Toke Høiland-Jørgensen <toke at toke.dk> writes:

> David Schinazi <dschinazi.ietf at gmail.com> writes:
>
>>>
>>>
>>> Why not? If it's not MTI you risk the case where you get to pick between
>>> "good performance on weak devices" and "interoperability with RFC-only
>>> implementations".
>>>
>>
>> Where are these "RFC-only implementations" of Babel?
>
> Anyone who does a from-scratch implementation from the RFC, without
> being part of the working group process, or looking at the existing
> implementations.
>
>> Remember the IETF does not have a protocol police, MTI is purely
>> guidance. Implementors build what they (or their customers) need for
>> their use-case. Implementors will add Blake if they need it, not based
>> on whether it's MTI or not.

It is generally my experience that anything that's a MAY or
SHOULD... doesn't get implemented.

RIPEMD is an artifact of the original hmac RFC.

>
> If it's MTI, they can't claim compliance with the RFC until it's in
> there. So the "we need this box checked" type of product development
> will benefit from this; and while sure, theoretically MTI is a hint,
> it's a pretty strong one...
>
>> Lastly, remember that this is a security solution, so you do NOT want
>> to interoperate with a future theoretical implementation, because that
>> will not have the keys. Adding any new node in the network will
>> require a provisioning step, and that step ensures the new node
>> supports the required features.

Upgrading any old node to an alternate algorithm is considerably
more difficult. 2 HMAC algorithms with a different design history is
comforting.


>
> You can usually control the config, but not necessarily the features
> implemented by the device...
>
> -Toke
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users