On 3/28/14 9:10 , "Johannes Merkle" <[email protected]> wrote:
>>>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'm confuded. Does Suite-B specify the truncation of HMACs? No it does not, AFAIK. AFAIK, it specifies: (a) a block cipher, (b) a set of hash-functions, (c) a digital signature algorithm, and (d) a key agreement algorithm. Truncation is probably specified in some of the RFCs produced *based on* the Suite B spec. I thin they're in line with IPsec, i.e., HMAC-SHA1-96. >I'm fine with SHA512 HMAC being only a SHOULD. Let's have it then. >256 bit output length is enough to prevent >birthday-paradox/digest-guessing attacks (which require n^(1/2) outputs), Yes, that means 256-bit output provides 2^128 digest-guessing resistance. >thus I prefer HMAC256SHA512 over HMAC384SHA512. I'm OK with it. I'm also OK with removing HMAC384SHA512 altogether, in favor of HMAC256SHA512. > For SHA-256 the situation is different, as collecting 2^64 outputs is >not so completely unthinkable (albeit still not practical). :-) >Thus, I suggest defining usmHMAC192SHA256AuthProtocol as MUST, and >usmHMAC256SHA512AuthProtocol as SHOULD. I'm OK with it. >>>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...? > >Yes, I'll do that next week. :-)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
