Subject: [OPSAWG] Stephen Farrell's Yes on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 14 May 2015 06:47:56 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 14 May 2015 09:58:31 -0400

Sent from my iPhone

> On May 14, 2015, at 9:47 AM, "Stephen Farrell" <[email-masked]> wrote:
> 
I agree with Stephen.  My yes was because more secure options are defined, but less would be good.

Thanks,
Kathleen

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 18 May 2015 17:46:08 +0200

> I agree with Stephen.  My yes was because more secure options are defined, but less would be good.

There was some discussion on this (admittedly by quite few participants) and my summary was as follows

> Question 3: Which (sub)set of protocols (hash function, MAC length) should be selected?
> - Johannes: SHA-256-192 as MUST, SHA-512-256 as SHOULD, all other can be MAY or omitted.
> - Uri: SHA-256-192 and SHA-384-320 as MUST, SHA-512-256 as SHOULD, and SHA-224-??? as MAY
> - Tom: AFAIU, he agrees with the preferences expressed by David, Johannes and Uri.
> - David: SHA-256-192 and SHA-512-384.
> (In all the above cases, the preferences were not that strong, there was mainly the wish to reduce the number of
> protocols in the current draft.)

Then I suggested the subset as it is currently defined and everyone agreed. It was a compromise. But considering the
individual opinions, It would be safe to delete the SHA-224 option.

-- 
Johannes

---

From: Warren Kumari <[email-masked]>
Date: Mon, 18 May 2015 18:24:48 +0200

> individual opinions, It would be safe to delete the SHA-224 option.

Fine with me (chair / doc shepherd)

W

(this email not actually needed, but figured it'd didn't hurt to mention :-))

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 May 2015 17:30:48 +0100

> individual opinions, It would be safe to delete the SHA-224 option.

Thanks for taking the time to discuss this, and eliminating some
options is good.

That said, I (still:-) think we're slightly doing the wrong thing here;
the additional options offer no real security benefit in this context
that I can see and nor does the truncation and the existence of
options has downsides. I suspect developers, testers and those
deploying might curse us for being a committee of compromisers:-)

But I asked and you thought about it, so in the absence of new
information, we're all set,

Thanks,
S.