Stephen Farrell's comment ( and former dicuss) I think should be food for thought and I'd like if possible to briefly discuss it.
------ I'm a yes on this, but am still holding my nose:-) The yes is because it's a fine thing to make sure that up-to-date options for securing protocols are available The nose-holding is because defining multiple options that aren't significantly different in strength (if one assumes that key management is the likely weakest link) is a bad plan. In case it helps, my main logic for not wanting all these options is that it is overwhelmingly more likely that the code to switch between them or react to which you've received or to configure things will (due to bugs etc.) weaken security much much much more than the existence of more than one of these options could ever strengthen security. (Put another way the probability of a security bug due to adding N things here is far far higher than the probability that having N things saves the day when N-1 of them are no longer considered good crypto at some point.) So by defining more of these you are doing worse than if you only defined one of these. (The fact that all sha2 digests have the same internal structure is part of but not all of this argument.) On truncation, I'd argue that if that was a significant benefit then it'd be used everywhere and it is not. In fact I don't believe truncation is used anywhere else when there's no protocol (e.g. PDU/fragmentation) issue that causes us to want shorter MACs. I also believe that even those who for truncation would agree that the benefit of reasonable-length truncation is definitely an insignificant benefit, if any, and would also agree that that's a matter of taste when it comes to sha2 variants of hmac (assuming the protocol can live with full length, as in this case). Bottom line: Discuss is cleared and I'm out of the way, but with a heartfelt plea that you ditch all of these but one. And then ditch truncation too. And so end up with just adding hmac-sha2 as many other protocols have done. ------- so there's a plea for limiting the scope of options, if someone feels very strongly that this is important to address I would take that under advisement. on the other hand reasoned countervailing arguements would also be fine but are certainly not critical.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
