Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt

From: Johannes Merkle <[email-masked]>
Date: Tue, 17 Feb 2015 14:53:53 +0100

Tom,

>>> > > s9.2
>>> > > is it the length of the key that gives it strength or its entropy? 
>>> > > Is abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004
>>> > > really stronger than !qaurk/99SS~ ?
>> >
>> > Strictly speaking, you are right, but it is common sense that
> cryptographic keys should have maximum entropy, i.e., they
>> > should be selected uniformly at random from bit string of that length.
> Consequently, virtually all cryptographic papers
>> > and text books use key the key length synonymous to its entropy. Thus,
> I consider this distinction as unnecessary.
> 
> Yes but, consider the audience.  Cryptographic material is aimed at
> cryptographers who know about entropy without being told, the audience
> of this I-D is all sorts, including MIB module specialists whose
> knowledge of cryptography is probably less than useless.  So I think
> 'length' is wrong, 'entropy' is probably too technical (especially if,
> like me, Thermodynamics was part of your degree), RFC5310 uses 'size and
> quality of the key' which is probably a good compromise.
> 

This section is about the influences of the cryptographic parameters of HMAC on the security.
The entropy or quality (I don't like that term) of the key is not a parameter, thus, it is not appropriate to mention is
along the size. I suggest the following wording:

  The security of each HMAC-SHA-2 authentication protocol depends on the parameters
  used in the corresponding HMAC computation, which are the length of the key
  (if the key has maximum entropy), the size of the [...]

Rational: If the key's entropy is not maximal, the length does not necessarily influence the the security.
abcdabcdabcdabcdabcd is not necessarily more secure than abcdabcdabcdabcd. At least, the key length is not a primary
parameter in this case. On the other hand, it is best cryptographic practice to choose keys uniformly at random, so that
their entropy is maximal.

-- 
Johannes

---

From: t.petch <[email-masked]>
Date: Tue, 17 Feb 2015 18:12:58 +0000

----- Original Message -----
From: "Johannes Merkle" <[email-masked]>
To: "t.petch" <[email-masked]>; "Warren Kumari" <[email-masked]>
Cc: <[email-masked]>; "Scott Bradner" <[email-masked]>
Sent: Tuesday, February 17, 2015 1:53 PM

> >>> > > Is
abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004
> The entropy or quality (I don't like that term) of the key is not a
parameter, thus, it is not appropriate to mention is
>   (if the key has maximum entropy), the size of the [...]

OK,

Tom Petch

> abcdabcdabcdabcdabcd is not necessarily more secure than
abcdabcdabcdabcd. At least, the key length is not a primary
> parameter in this case. On the other hand, it is best cryptographic
practice to choose keys uniformly at random, so that

---

From: Warren Kumari <[email-masked]>
Date: Tue, 17 Feb 2015 15:15:51 -0500

Apologies for the delay - Scott and I were planning on meeting in
Singapore to discuss a bunch of OpsAWG stuff, but the scheduling
didn't work out (we were there for different meetings and he arrived
just before I left...)

Anyway, yup, Standards Track (which you've already done, this just
closes the loop...)

On Fri, Jan 30, 2015 at 5:22 AM, t.petch <[email-masked]> wrote:
> Warren
>
> One of the points I raise below calls for input from the WG Chairs.
>
> The registry that is being updated
> http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xh
> tml#snmp-number-spaces-5
> requires Standards Track for updating.  The current I-D is
> Informational.  This will hit a brick wall when it reaches IANA (I-d
> Advancement Not Admissible).
>
> Johannes wisely said that that he would look for the agreement of the
> chairs for this change.
>
> Do you agree?
>
> Tom Petch
>
> Sent: Thursday, January 29, 2015 8:03 AM
>
>> Tom,
>>
>> thanks for the thorough review. This really helps improving the
> document.
>>
>> > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a
>> > Normative reference.  RFC6234 is not Standards Track but that is ok,
> it
>> > is already in the list of IESG permitted downrefs (does that need
>> > calling out at IETF Last Call?)
>>
>> You are right, but the question is whether I should rather use
> references [RFC2104] and [SHA] here.
>>
>> >
>> > s9.1
>> > /apply the use /apply to the use /
>>
>> Right.
>>
>> >
>> > s9.2
>> > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I
> think
>> > that s9.4 should reflect that (lest it confuses, or am I confused
> having
>> > missed an OBJECT somewhere?)
>>
>> Here I definitely need help, as I have no knowledge about MIBs.
> Actually, I copied that section from RFC 3411. Please
>> give advise what to write here or if this section is needed at all.
>>
>>
>> > The names used for the four protocols are not consistent within the
>> > document.  Following RFC3414, I think that including Auth is
> correct.
>> >
>> oops, this escaped my attention.
>>
>> > Updates to this registry requires a Standards Track document which
> this
>> > is not.
>>
>> Wright. If the chairs agree, I'll change the track.
>>
>> >
>> > MIB Module copyright is 2004
>>
>> opps again. Copy and paste error.
>>
>> >
>> > Does this document update RFC3414?  It adds to the registry that
> that
>> > RFC created which some ADs say is NOT an update, some ADs say it IS
> an
>> > update; I think that we need guidance here (the update by RFC5590 of
>> > RFC3414 is a whole different ball game).
>>
>> I will wait for the guidance here.
>>
>> --
>> Johannes
>

-- 
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: Warren Kumari <[email-masked]>
Date: Tue, 17 Feb 2015 16:48:42 -0500

And I *think* that this addresses the open questions (see Joel's
response on the "adding an entry to a registry" question) - please
feel free to poke me is I missed any...

While having another look before starting the WGLC I found a few more
minor nits.

1:
Values of constants M (the length of the secret key) and N (the length
of the MAC output) used below, are:
usmHMAC128SHA224AuthProtocol: M=28, N=16;
..."
it might be nice to say that M and N lengths are octets. This should
be blindingly obvious from the text in Section 4.1, but doesn't hurt.

2:
Your instructions to the RFC Ed contain an off-by-one type error:
" ::= { snmpAuthProtocols bb } -- bb to be assigned by IANA
    -- RFC Ed.: replace cc with actual number assigned by IANA &
remove this line"
3:
-02 still has a reference to RFC4231, which isn't used in the doc.

Other:
There are still some downward references to Informational documents,
which is a process issue I've not had to deal with recently, and so
have forgotten the procedure...
I poked around and there are ~80 Standards Track documents that have
Normative downrefs to RFC2104, and 3 that reference RFC6234.
RFC3967 (Clarifying when Standards Track Documents may Refer
Normatively to Documents at a Lower Level) says that the normal last
call happens, and we note that there are downward refs. If the AD
believes that this is a well known case, they may waive this bit.
Entertainingly enough, it also uses RFC2104 as an example of this
("For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well
known among cryptographers.").
So, I think we can go ahead with this and I'll make a note when we
send it over to our AD and he can deal with it.

While we *could* note these in the WGLC call, I think it would be
cleaner if you could post a new version, and then I think we can kick
off the WGLC.

W

---

From: t.petch <[email-masked]>
Date: Wed, 18 Feb 2015 10:46:42 +0000

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "Johannes Merkle" <[email-masked]>
Cc: <[email-masked]>; "Scott Bradner" <[email-masked]>; "t.petch"
<[email-masked]>
Sent: Tuesday, February 17, 2015 9:48 PM

Warren

You go to the website and see if they have already been approved.

http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry#

(2104 6234 have and the latter has a Normative Reference to FIPS 180-3
which should serve although a strict reading of the web page says not;
but then a strict reading of the web page says that Russ Housley should
have caused the FIPS document to have been added to the web page which
it wasn't).

Then it is up to the AD to see if they warrant a mention in IETF Last
Call using the information that the Document Shepherd has put in section
15.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Wed, 18 Feb 2015 10:54:33 +0000

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "Johannes Merkle" <[email-masked]>
Cc: <[email-masked]>; "Scott Bradner" <[email-masked]>; "t.petch"
<[email-masked]>

>     -- RFC Ed.: replace cc with actual number assigned by IANA &

It's not one off.

There is a similar mismatch for 'cc' and 'dd' and 'dd' and 'ff'

Tom Petch

---

From: Warren Kumari <[email-masked]>
Date: Wed, 18 Feb 2015 09:58:28 -0500

> Call using the information that the Document Shepherd has put in section

Oh, excellent. Thank you, my search foo failed me...

W