[Dime] Ben Campbell's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-dime-e2e-sec-req-04: No Objection

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-dime-e2e-sec-req/



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

Substantive:

- I am concerned about the de-emphasis of privacy requirements. While
there's a mention of confidentiality in Requirement 2, other text
suggests that integrity is more important (implying privacy is less
important). There are no privacy considerations. Finally, the  {AVP}k
convention does not distinguish  hinders discussion about how the set of
confidentiality-protected AVPs and integrity-protected AVPs might not be
the same. [Note: I almost balloted DISCUSS over this point. I did not,
because I don't want to force the working group to add requirements it
doesn't believe in. But I'd like to see some discussion about this.]

- The "middle to *" models may be useful, but they are not end-to-end.
Given the focus on those models, I find the title of the draft to border
on disinformation. The description in the introduction about protecting
AVPs between "non-neighbor" nodes is more accurate.

- I find it odd to find 2119 keywords in the "motivation" sections. I
suspect that most of those are statements of fact. If some are really
requirements, they should be presented as such.

- 4: The listed advantages of the middle-middle model (and also
middle-to-end and end-to-middle) seem to assume that the number of
"middles" is smaller than the number of "ends". While this may be true,
especially for clienty ends, it should probably be explicitly stated.

-- "firewalling Diameter proxy" needs a definition or reference.

- Requirement 1: Does this need discussion on deprecating algorithms when
vulnerabilities become known?

- Requirement 2: Please elaborate on backwards-compatibiltiy with
existing applications. Is this intended to motivate the models with
"middles"?

- Requirement 7: This (along with some text in the introduction) implies
that non-repudiation is a requirement. If so, that should be listed and
elaborated as a requirement.

Editorial and Nits:


- 1, first paragraph: "mechanisms independent of Diameter (e.g., IPsec)
   is used."

s/is/are

- Requirement 3: The last sentence seems to ask the reader to draw a
conclusion that wall-clock time can be used for anti-replay protection.
If that's the intent, please say so explicitly.