On 06/05/16 21:28, Joe Clarke wrote: > On 5/4/16 18:11, Stephen Farrell wrote: >> Hi Joe, >> >> Those are all fine changes. Couple of tweaks suggested below. > > Thank you for your suggestions, Stephen. Please find a new proposed set > of text changes at > http://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html > . We believe they satisfy your discuss items.
Yep, post that and I'll clear, Cheers, S. > > Joe > >> >> 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
