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." 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
