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

[Stephen Farrell <[e-mail]>]

Hiya,

On 14/05/15 14:18, t.petch wrote:
> ----- Original Message -----
> From: "Stephen Farrell" <[e-mail]>
> To: "The IESG" <[e-mail]>
> Sent: Thursday, May 14, 2015 10:09 AM
> 
> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Discuss
>>
>> 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?
>>
> 
> 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:-).

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.


> 
> Tom Petch
>