Another stray thought. I see RFC3412 in the references but cannot see it referenced in the text.
And Juergen has responded on the question of what to put in the Security Considerations so ignore my comments on that. Tom Petch ----- Original Message ----- From: "t.petch" <[email protected]> To: "Johannes Merkle" <[email protected]>; "Warren Kumari" <[email protected]> Cc: <[email protected]>; "Scott Bradner" <[email protected]> Sent: Thursday, January 29, 2015 10:30 AM Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt > ----- Original Message ----- > From: "Johannes Merkle" <[email protected]> > To: "t.petch" <[email protected]>; "Warren Kumari" <[email protected]> > Cc: <[email protected]>; "Scott Bradner" <[email protected]> > 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. > > Don't know - this is the gory detail which I did not pursue - really > need an implementor to say if the older references are adequate for > SHA2; but as I say, a Normative reference to RFC6234 is fine if we want > it > > > > s9.1 > > > /apply the use /apply to the use / > > > > Right. > > > > > > > > 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. > > > > 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. > > RFC3826 is a good parallel here - it omits this paragraph entirely so I > would do the same, unless Juergen, Bert or Randy say otherwise. > > No further comments on the points outstanding below (Standards Track I > consider a must, Updates RFC3414 not needed unless our AD requires it). > > Tom Petch > > > > > 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 > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
