> Johannes wrote on 27.08.2014 19:46: > > The purpose of our delta-description was to make clear that the basic protocol > design of RFC 3414 does not change (only the hash function and the lengths of > some data) and to facilitate implementation. Existing implementations of the > RFC > 3414 auth protocols can be easily modified. No need to implement the protocol > from scratch. > > In contrast, your description is very different from that in RFC 3414. So an > implementor would need to re-implement the protocol from your description. I > don't see why this should be less error-prone.
Being different from RFC3414 doesn't mean that our method (draft-hartman) needs a re-implementation. Actually both drafts are quite different from RFC3414, 'draft-hartman' describes the SHA2 for USM in terms of key selection, outgoing message generation, incoming message processing, which concisely and clearly follows the logic of USM. But ' draft-hmac' makes diversion to the truncation issue and its definition to MIB. What really matters here is whether the mechanism is fit for USM and as you agree, whether the mechanism is easy and practical to be implemented. > But I am open to the approach of providing both types of description. > > > > > > In addition, I'm not convinced that truncating the HMAC is a good idea > > Many well-reputed cryptographers (e.g. Preneel and van Oorschot) advocate > HMAC truncation. Could you please elaborate on why you think that truncation > is not a good idea? > Truncation is advocated doesn't mean that it is convinced to be freely applied anywhere. Truncation is actually a weighted trade-off decision, it is open to discuss and will not end up with a best conclusion. Normally the uncertainty of the parameter selection should be out of the scope of a draft. Although I admit that by truncating the output length the 'attacker can learn less about the output of the compression function', it actually increases the risk of security and the complexity of the implementation. Both of the drafts use SHA2 as an enhancement due to the already known disadvantage of SHA1 and MD5. Implementing SHA2 means that the output length will definitely exceed the 12 octets reserved for msgAuthenticationParameters and we can foresee a modification of the SNMP packet format. I didn't see the advantages by truncating SHA2 to different confusing output lengths and increase the risk of the security and complexity of implementation. > > in this instance. If the WG decides that truncation of the HMAC is > > desirable, we should add a description of why that's the case and a > > security discussion. (I don't think the truncation proposed has > > significant security problems) > > We have included a detailed discussion in Security Considerations. > It would be better when truncation length be discussed only in the security considerations, truncation issue is more academia and might not be suitable to be proposed as a formal mechanism in the main content of the draft. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
