Hedanping (Ana) wrote on 28.08.2014 06:40: > >> 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 do you mean by "' draft-hmac' makes diversion to the truncation issue"? RFC 3414 also uses truncated HMACS, so there is no deviation in this. > > 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. > We should not mix up these two topics: 1) Should we use truncation and, if yes, to what extend (50% or 75%)? 2) How many protocols should we specify? As to 1), I have already elaborated on the reasoning for truncation http://permalink.gmane.org/gmane.ietf.opsawg/3244 and there was some discussion on this, where most participants expressed their preference for truncation. Your statement that truncation "increases the risk of security" probably refers to the reduction of strength against collision attacks, which require n^(1/2) collected messages. At least for the protocols with HMAC output length of 192 bits or greater, we can safely consider such attacks as impractical in the foreseeable future. Just to be sure that there is no misunderstanding: The security issues of TLS with HMC truncation are caused by the MAC-then-PAD-then-Encrypt construction of TLS, see http://web.archiveorange.com/archive/v/aFZ9KRJi4JLUvLRo8Ek7#HF6Jnaf1plca1DC Are you strictly objecting to truncation or is it just not your preference? As to 2), there was already some discussion on this list where, and many expressed a preference for cutting down the list. You can find the thread here: http://comments.gmane.org/gmane.ietf.opsawg/3237 I am open to reducing the number of protocols, we just need to agree on how many and which protocols we want. If there is consensus on this list for a set of protocols, even if they do not use truncation, I will not object. > 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. > I don't get it: truncation length _is_ discussed only in the security considerations. What exactly are you objecting to? -- Johannes _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
