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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 14 May 2015 02:09:25 -0700

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

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for defining these. I do have a thing do briefly
discuss before balloting yes. I'll be getting out of your way
very shortly, but I want to check first to see if you agree
with me that this could be simpler and more useful.

I note the following:

- You're defining a bunch of HMAC options. 
- Additional options for fun isn't a good idea with crypto.
- There may be platforms that do not have good APIs for 
  SHA224 or SHA384.
- HMAC-SHA256 without any truncation is considered perfectly 
  fine for this purpose and is widely used elsewhere.
- You don't need truncation for protocol reasons.

To me, that implies that this would be better if it *only*
defined a non-truncated HMAC-SHA256 option and if all of the
rest were removed.

Do you agree that doing so would achieve just as much of a
security improvement, but with less complexity for
implementation, test and interop? If so, should we just do
that?

---

From: t.petch <[email-masked]>
Date: Thu, 14 May 2015 14:18:13 +0100

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "The IESG" <[email-masked]>
Sent: Thursday, May 14, 2015 10:09 AM

Stephen,

This was raised prior to adoption by OPSAWG, advice was sought and Uri
Blumenthal said, 23 Sep 14

"
I am for HMAC truncation.
"
and
"
There probably is no doubt that protocols based on SHA-256 and SHA-384
need to be there. SHA-512 might cause some raised brows, as could
SHA-224.
I still would add them - SHA-512 as SHOULD, and SHA-224 as MAY.
"
which convinced me to support the current position.  (At one stage, the
list was even longer:-).

Tom Petch

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 May 2015 14:40:15 +0100

Hiya,

> which convinced me to support the current position.  (At one stage, the

Yeah, that's the problem with advice I guess - it's not
always the same:-)

I'll clear the discuss since the WG considered the issue (even
if briefly) and because there are matters of personal preference
here where good folks differ.

But fwiw I still think adding more unnecessary options as
is being done here is just a bad plan so I'm holding my nose
whilst doing that;-)

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: I'll clear and get 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.

S.