Re: [MIB-DOCTORS] Change the boilerplate - Alissa's DISCUSS

["ietfdbh" <[e-mail]>]

" adding a special section or extra text to discuss privacy
concerns in the IoT-related documents is the right way to go."

+1

David Harrington
[e-mail]
[phone]

> -----Original Message-----
> From: MIB-DOCTORS [mailto:[e-mail]] On Behalf Of
> Alissa Cooper
> Sent: Thursday, July 10, 2014 11:28 AM
> To: Juergen Schoenwaelder; Benoit Claise
> Cc: Adrian Farrel; [e-mail]; MIB Doctors (E-mail)
> Subject: Re: [MIB-DOCTORS] Change the boilerplate - Alissa's DISCUSS
> 
> Perhaps rather than re-discussing the boilerplate, we could discuss what
> the purpose of the boilerplate is.
> 
> If the purpose of the boilerplate is to provide text that authors can look
> at and say, “yes, in the case of this document, the boilerplate fully
> covers the security considerations of the MIB being specified,” then I
> think it’s a great thing to have. If the purpose of the boilerplate is to
> keep any additional security consideration not covered in the boilerplate
> from being addressed in a MIB document, then it seems overly constricting.
> 
> Security considerations change over time. I’m assuming that home/device
> energy monitoring wasn’t really top of mind when SNMP was developed or
> when the boilerplate was originally written. So it’s not surprising that
> new security issues are arising that aren’t addressed within the
> boilerplate. If the boilerplate were just a suggestion of text and not a
> limitation on what can be documented, we could accommodate the changing
> times fairly easily.
> 
> In my original DISCUSS, all I suggested was text that could be provided in
> addition to the boilerplate:
> 
> "In certain situations, energy and power monitoring can reveal sensitive
> information about individuals' activities and habits. Implementors of this
> specification should use appropriate privacy protections as discussed in
> Section 9 of RFC 6988 and monitoring of individuals and homes should only
> occur
> with proper authorization.”
> 
> I have not had time to look at Stephen’s comments but I agree with him and
> Bert that adding a special section or extra text to discuss privacy
> concerns in the IoT-related documents is the right way to go.
> 
> Alissa
> 
> 
> On 7/10/14, 8:11 AM, "Juergen Schoenwaelder"
> <[e-mail]> wrote:
> 
> >On Thu, Jul 10, 2014 at 04:13:08PM +0200, Benoit Claise wrote:
> >> Dear all,
> >>
> >> The email below refers to Alissa's DISCUSS
> >> See
> >>
> >>http://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-
> mib/bal
> >>lot/#alissa-cooper
> >>
> >> Alissa refers to this sentence in the boilerplate at
> >> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
> >>
> >>         Implementations SHOULD provide the security features described
> >> by the
> >>         SNMPv3 framework (see [RFC3410]), and implementations claiming
> >> compliance
> >>         to the SNMPv3 standard MUST include full support for
> >> authentication and
> >>         privacy via the User-based Security Model (USM) [RFC3414] with
> >> the AES
> >>         cipher algorithm [RFC3826].
> >>
> >> From the discussion (Dan andBert's feedback, on top of mine) , it seems
> >> that there are valid reasons to keep a SHOULD here in the generic
> >> boilerplate.
> >>
> >> So what next?
> >> - Should we justify the reasons in the boiler plate
> >> - Should we  give some freedom in the boilerplate?
> >>
> >>         Implementations SHOULD provide the security features described
> >> by the
> >>         SNMPv3 framework (see [RFC3410]), and implementations claiming
> >> compliance
> >>         to the SNMPv3 standard MUST include full support for
> >> authentication and
> >>         privacy via the User-based Security Model (USM) [RFC3414] with
> >> the AES
> >>         cipher algorithm [RFC3826].
> >>
> >>         <if there are use cases where a MUST is required, described
> >> them here>
> >>
> >>   Now, I hope it will not be abused by Security ADs, requesting a MUST
> >> for every single MIB module.
> >> - Something else?
> >> - Stop writing MIB modules :-)
> >>
> >
> >Do nothing, re-discuss this every other year. ;-)
> >
> >/js
> >
> >--
> >Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> >Fax:   [phone]         <http://www.jacobs-university.de/>
> 
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mib-doctors