On 3/27/14 10:23 , "t.petch" <[email protected]> wrote: >Right!
:-) >....a good model to follow, which Uri's suggestion does. :-) Yep! >As to how many, I am uncomfortable with giving implementers the choice >of eight along with the statement that you do not have to implement them >all, which, for me, invites a lack of interoperability, regardless of >whether or not the crypto libraries have all the options available so >making them easy to implement! Hmm... Yes, but the whole reason the NIST standard defined several was that different applications have different needs & requirements. Otherwise, why not just define/standardize SHA512, and say "if you need fewer bits - mix/truncate"? >So my thinking would be either a MUST implement for one, or recommend >that all should be implemented, with a >recommended order to choose, or some such - just not the current wording. I personally would be OK with this. One would be MUST, one or two would be SHOULD, the rest would be MAY in the given order. Yes it could affect interoperability, on the other hand - the market can help sorting this part out. :-) >As to MUST, this I-D will have to be Standards Track, not Informational, >in order to update SnmpAuthProtocols so the use of requirements language, >and the boiler plate thereon, is not an issue. I'd have no problem with this RFC going Standards Track. Johannes? >On Security, I have memories of discussions on the TLS list of the merits >of size and truncation. One reference I have found is 'SHA-1 is being >deprecated' from 2008 from one 'Uri' - so I think something along those >lines worth >including by way of justification for this I-D (Suite B got a lot of >mentions around that time). :-) Oh yes. And the TLS list discussion is an echo of the former IPsec list discussion. Not sure if it's a good idea to bring Suite B up at this time? >I have memories of an argument against the use of SHA-512, I think on the >grounds that the registers were not wide >enough and that the extra security did not justify the extra computation >required, but cannot find a reference for that. I don't recall that, probably didn't care back then. In any case, (a) I don't think these arguments apply now, and (b) SHA512 would be only SHOULD if things go the way I'd like... >As to degree of truncation, I understand the argument in principle but do >not have the mathematics to take a view as to what is best. I do note >that in 2006, it was suggested that the merit of truncation was to save >bandwidth in constrained environments - I don't know if that is now more >or less applicable. As Hugo Krawczyk (who was the key contributor and participant in that discussion) recently confirmed, the MAIN reason for truncation was bandwidth saving - but cryptographers found that it also offers some benefits. IMHO, saving some bandwidth is always a good thing, because you can never have too much of it. :-) Would like to hear from others on this subject, given that: - truncation saves bandwidth; - truncation improves resistance to key guessing attacks; - truncation lowers resistance to birthday-paradox/digest-guessing attacks. What do we _want_ (care about) here? >So I would like to see more in the Security Considerations along these >lines with a target audience of non-cryptographers. Johannes, would you put a few words there...? TNX! >----- Original Message ----- >From: "Johannes Merkle" <[email protected]> >To: "Blumenthal, Uri - 0558 - MITLL" <[email protected]>; "t.petch" ><[email protected]>; <[email protected]> >Cc: "Manfred Lochter" <[email protected]> >Sent: Tuesday, March 25, 2014 6:03 PM >> >> Blumenthal, Uri - 0558 - MITLL schrieb am 25.03.2014 16:52: >> > On 3/25/14 11:33 , "t.petch" <[email protected]> wrote: >> > >> >> I am confused by your choice of names. The text uses, e.g., >> >> usmHMACSHA224128AuthProtocol >> >> >> >> whereas the MIB module has >> >> >> >> usmHmacSha224128Protocol >> >> >> >> Do these refer to the same identity (times six)? >> >> Good catch! >> >> > >> > I think yes, and would suggest the following (unified) name format: >> > >> > usmHMAC128SHA224AuthProtocol >> >> I like this proposal, because it is easier to read. >> >> >> >> I think that the IANA Considerations needs more work; you might >want to >> >> review RFC4181 for a more detailed approach but you need at least >> >> something along the lines of an explicit request that the MIB >module be >> >> assigned a number under the appropriate tree, e.g.,.............. >> > >> > I'll leave this to Johannes to take care of. :-) >> >> Yeah, I'll take care of this. >> >> > >> >> And then there are Security Considerations. You are replacing a >simple, >> >> well understood choice of two values with a choice of eight, and >saying >> >> that there is no need to implement them all. This gives great >scope for >> >> a lack of interoperability. Should there be a mandatory to >implement >> >> value (or negotiation - perhaps not)? >> > >> > Can we have mandatory-to-implement in an "optional" RFC? >> >> AFAIK this is common. >> >> > Assuming the answer is yes, I'd recommend: >> > For those who implement this RFC, usmHMAC192SHA256AuthProtocol is >MUST, >> > usmHMAC384SHA512AuthProtocol is SHOULD, everything else is MAY. >Unless >> > there's a preference for the "non-truncated" algorithms. >> >> I had already received very positive feedback on the first draft >(which specified merely usmHMAC128SHA256AuthProtocol), >> .e.g. >> >> >> Thus, I have no clear preference here, but Uri's proposal is fine for >me. >> >> > >> >> I would like to see some discussion of the benefits, if any, of the >six >> >> new options. >> > >> > Do you mean "the benefits of having so many rather than just one or >two", >> > or do you mean "the benefits of adding SHA2-based auth"? >> > >> > If it's the first - then we probably can shrink the number of the >> > available choices. The question is - do we select truncated ones (as >the >> > prior standards did), or not? >> >> All versions use truncated HMAC, the difference lies in the degree of >truncation. You probably mean "do we select the >> variants using 50% truncation or those with 75% truncation?" >> >> I don't think that interoperability is really a big issue. Crypto >libraries typically support most, if not all SHA-2 >> hash functions. Futhermore, implementing two different lengths for >truncation is trivial. Thus, I do not see why anyone >> should implement usmHMAC384SHA512AuthProtocol but not >usmHMAC256SHA512AuthProtocol. >> >> But, yes, if required for WG consensus, I do not object to remove some >variants. >> >> > >> > If it's the second - I'll let others speak. :-) >> > >> >> From Tom's responses to our first draft, I understand that he does not >question that SHA2 based HMAC authentication is >> useful. >> >> > >> >> I have seen discussions along these lines on the TLS WG >> >> list (with a considerable degree of expertise in cryptography >present) >> >> that makes it far from clear cut what the best choice is, and that >what >> >> appears to be the strongest may not be a good choice for IETF >protocols. >> > >> > Honestly I don't think TLS WG is a good example here, considering >the >> > complexity of the protocol, and the kind of problems they're facing >and >> > are trying to address. But your point is taken. >> > >> >> I think Tom is referring to the discussion regarding MAC truncation, >which was a sideline of the discussion about the >> optimal order of encryption and MAC in TLS. >> http://web.archiveorange.com/archive/v/aFZ9KRJi4JLUvLRo8Ek7 >> http://web.archiveorange.com/archive/v/aFZ9KQVpfdL7WYG1B9l7 >> >> The second thread cites Bart Preneel saying >> "On the other hand, several (key recovery) >> attacks on MAC algorithms (including HMAC-MD4 and HMAC-MD5) >> have been found based on internal collisions. These attacks >> would become more difficult if fewer output bits are available. >> [...] >> My conclusion is that my intuition as cryptanalyst was correct >> and that it would be best to shorten the output of a MAC >> algorithm to half the internal state." >> This recommendation is also included in the seminal paper of van >Oorschot and Preneel (page 11) >> ftp://ftp.esat.kuleuven.ac.be/cosic/preneel/mdxmac_crypto95.ps.gz >> For the SHA-2 family, the length of the internal state is 256 bits for >SHA-224 and SHA-256 and 512 bits for SHA-384 and >> SHA-512 (recall that SHA-224 and SHA-384 are truncated SHA-225 and >SHA-512, respectively, with modified constants). This >> recommendation results in HMAC128SHA224, HMAC128SHA256, HMAC256SHA384, >HMAC256SHA512. >> >> On the other hand, shortening the output length reduces the strength >against collision attacks. Thus, we were not >> completely comfortable with the 50% truncation for SHA-256 and >SHA-512. On the other hand, AFAIK, there are no clear >> cryptanalytic results about truncation, let alone on the optimal >degree of truncation. For this reason, we also included >> HMAC192SHA256 and HMAC384SHA512. >> >> -- >> Johannes >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
