Hi Roman,
Many thanks for your further feedback. We just uploaded revision -17 to
address your comments.
HTML: https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-17
Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-alto-oam-yang-17
Please see our detailed responses inline below. If there are others needed,
please let us know.
Thanks,
Jensen
On Thu, Jan 18, 2024 at 10:50 PM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-alto-oam-yang-16: Discuss
>
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/
>
>
>
> --
> DISCUSS:
> --
>
> Per -15 ballot review:
>
> ** Section 8. Per the guidance on writeable data, aren’t significant
> parts of
> alto-server/listen sensitive as one could alter the stored keys for the
> server
> or client; or the username/password combinations (in
> http-server-parameters)?
>
> ** Section 8. Per the guidance about readable data:
>
> -- isn’t tls-server-parameters sensitive since it could contain raw private
> keys (e.g., ks:inline-or-keystore-symmetric-key-grouping)?
>
Agree. We should make it clear. Writeable data nodes in
'http-server-parameters' and 'tls-server-parameters' are sensitive. We
added the list of the concrete sensitive data nodes and their referenced
groupings and modules. The security considerations of the corresponding
I-Ds are applied to them.
>
> -- Would it be best practice to be able to read all of the authorized
> users?
>
The admin should be able to operate the access control of the authorized
users. Therefore, accessing the identifiers of the authorized users is a
minimal requirement. But more sensitive user information is not required.
>
> Thanks for the response at
> https://mailarchive.ietf.org/arch/msg/alto/tD88zktK20QDBIbd-jbGt5JJDLc/
>
> > Yes, some groupings in alto-server/listen are also sensitive. But they
> are
> > defined in other RFCs, thus the security considerations in those RFCs
> also
> > apply to them.
>
> This described approach is inconsistent with my observation on how the YANG
> security template is used. If there is a path which has security
> considerations, the issues are typically highlighted regardless of whether
> there is reuse. Setting aside that this is a YANG module, my experience
> with
> any protocol document is that if there is a mechanism reused by reference
> and
> it introduces a relevant security dependency, it would have been cited in
> the
> Security Considerations as applicable. Neither of these approach appear
> to be
> taken here. Is there a reason why not?
>
Make sense. We added the security considerations for the reused data nodes.
>
>
> --
> COMMENT:
> --
>
> Thank you to Rich Salz for the SECDIR review.
>
> Thank you for addressed by COMMENT and DISCUSS feedback.
>
>
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
