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

[Jouni Korhonen <[e-mail]>]

Kervin is not with Oracle anymore. I haven't managed to reach him yet.

- Jouni



6/1/2016, 8:45 AM, Ben Campbell kirjoitti:
> By the way, <[e-mail]> bounces. Is there an updated address?
>
> Ben.
>
> On 1 Jun 2016, at 11:23, Ben Campbell wrote:
>
>> 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.