Subject: [OPSAWG] draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 about to send to the rfc editor.

From: joel jaeggli <[email-masked]>
Date: Wed, 17 Jun 2015 22:21:40 -0700

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.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 22 Jun 2015 14:30:49 +0000

>for thought and I'd like if possible to briefly discuss it.

It has already been discussed (briefly), both among the designers, and
with the wider audience, including Stephen. We evaluated the arguments
(and their accuracy), weighted them against the other reasons (such as
providing a standardized auth method for standardized hashes), and decided
what should stay in the draft.

In summary, the decision was to provide a mandatory method, but in
compliance with the standard SHA-2 specs define optional mechanisms
pairing with the SHA-2 hash family members. Reason: those who for whatever
reason need a hash from SHA-2 family, would have a *standard* way to use
it within this spec.

Is there anything not covered in the arguments Stephen made (some of which
I disagree with, but it’s besides the point) and my answer above?

---

From: joel jaeggli <[email-masked]>
Date: Wed, 24 Jun 2015 08:40:08 -0700

> I disagree with, but it’s besides the point) and my answer above?

No, I think that's good.

Thanks
joel

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 24 Jun 2015 17:49:14 +0200

needless to say that I agree with that ;-)

Johannes

joel jaeggli schrieb am 24.06.2015 um 17:40:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>