Sent from my iPhone
> On May 4, 2016, at 6:11 PM, Stephen Farrell <[email protected]> wrote: > > > Hi Joe, > > Those are all fine changes. Couple of tweaks suggested below. > >> On 04/05/16 22:59, Joe Clarke wrote: >> 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." > > Two things:- > > - the last bit isn't quite right, it's more the impact is greater > if the leak happens (the risk of a leak is presumably proportional > more to how long the system is operated). > - you didn't mention that in some places there could be legislation > imposing a min and/or max on retention of some kinds of data. > > So I'd suggest instead: > > "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 higher the > impact it were to be leaked. It is also possible that > legislation may impose some requirements on the minimum and/or > maximum durations for which some kinds of data may be retained." > I like the suggested text having led a number of information management projects that included data retention, I agree with Stephen and appreciate the updated text. Thanks, Kathleen > If you think it's important to not say that last bit please > do make that argument. > > (I'll clear the discuss when you post a revision with the > above unless one of the other ADs who agreed with the > discuss chimes in to say otherwise.) > >> >> Would you prefer I make reference to this in the Security Considerations >> as well? > > Your call. So long as it's there somewhere I think we're sorted. > And the rest below is fine. > > Cheers, > S. > > >> >>> >>> >>> ---------------------------------------------------------------------- >>> 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
