Blumenthal, Uri - 0558 - MITLL wrote on 27.03.2014 17:46: > On 3/27/14 10:23 , "t.petch" <[email protected]> wrote: >> ....a good model to follow, which Uri's suggestion does. > > :-) Yep!
Ok, I will change names accordingly. >> 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. I agree. As soon as we have agreed on the mandatory and recommended protocols, I will include these provisions. >> 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? No, and we have no choice anyway. >> 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? > >> 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... > I'm fine with SHA512 HMAC being only a SHOULD. >> 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. 256 bit output length is enough to prevent birthday-paradox/digest-guessing attacks (which require n^(1/2) outputs), thus I prefer HMAC256SHA512 over HMAC384SHA512. 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. >> 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. -- Johannes _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
