On 5/4/16 12:43, Stephen Farrell wrote:
Thanks for your feedback, Stephen.
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Intro: I don't agree that all data retention aspects are
out of scope here. They are about as in-scope as log
rotation I'd say. I do think it'd be worthwhile noting that
if log content contains sensitive data (either security- or
privacy-sensitive) then retaining that data for extended
durations has a cost, in terms of creating risks if data
leaks. While one cannot say here how to evaluate such
risks, they do exist and should really be noted. It would
also be sensible IMO to say that implementations SHOULD
provide a way to purge ancient log content that is no
longer needed or useful, but that the definition of when
content is no longer needed or useful is out of scope. In
saying this I do recognise that much or perhaps even most
i2rs log content will not be security or privacy sensitive,
but in some cases it can be, e.g. if an operation involved
an address that is specific to a user or device carried by
a user. In addition, some data retention regimes could
impose a requirement to purge log content after a certain
duration. I'd say a note about this in the intro or in the
security considerations should be a fine way to handle this
issue, and to acknowledge that not all data retention
issues are out of scope for implementations.
Would changing the Trace Log Temporary Storage section alone be
sufficient? I have changed that section to read:
"It is outside the scope of this document to specify the
implementation details (i.e., size, throughput, data
protection, etc.) for the physical storage of the
I2RS log file. In terms of data retention,
attention should be paid the length of time I2RS trace log
data is kept when that data contains security or privacy-sensitive
attributes. The longer this data is retained, the more risk is incurred
if it were to be leaked."
Would you prefer I make reference to this in the Security Considerations
as well?
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
- 5.2: Requested/Applied Operation Data - I would guess
this can include sensitive values, e.g. keys/passwords.
Shouldn’t you say to at least be careful of those, or
perhaps to not log them, or to zero out known sensitive
values before logging?
There is text in the Security Considerations section that says:
"Additionally, the potentially sensitive information contained in a log
file SHOULD be adequately anonymized or obfuscated by operators to
ensure its privacy."
Are you suggesting we explicitly call out the Op Data fields here?
- 7.2: how is privacy an implementation detail?
I pulled out privacy.
- 7.4: What does "being preferred" mean in 2119 terms? Why
is one of the three options not mandatory-to-implement?
The current [un-published] version makes pub-sub MTI.
Joe
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
