> Yep, all of which speaks to some serious shortcomings of the > HMAC-based protocol.
The scope of Babel-HMAC is deliberately limited. Babel-HMAC aims to implement the strict minimum of features that make it useful. Any deployment that needs features beyond what Babel-HMAC provides should use Babel-DTLS instead. > If N^2 is feasible, it would be good to hear how those keys are managed. Not in Babel-HMAC, no. We've tried to be very clear about that in Section 1.1 of draft-ietf-babel-hmac-00 : The protocol defined in this document assumes that all interfaces on a given link are equally trusted and share a small set of symmetric keys (usually just one, two during key rotation). The protocol is inapplicable in situations where asymmetric keying is required, where the trust relationship is partial, or where large numbers of trusted keys are provisioned on a single link at the same time. This protocol supports incremental deployment (where an insecure Babel network is made secure with no service interruption), and it supports graceful key rotation (where the set of keys is changed with no service interruption). This protocol does not require synchronised clocks, it does not require persistently monotonic clocks, and it does not require any form of persistent storage. If you believe this deserves further clarification, we'll be grateful for your guidance. -- Juliusz _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
