Toke Høiland-Jørgensen <[email protected]> writes: > David Schinazi <[email protected]> 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 > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
