Subject: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 04 May 2016 09:43:32 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-i2rs-traceability-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
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?

- 7.2: how is privacy an implementation detail?

- 7.4: What does "being preferred" mean in 2119 terms? Why
is one of the three options not mandatory-to-implement?

---

From: Joe Clarke <[email-masked]>
Date: Wed, 4 May 2016 17:59:01 -0400

On 5/4/16 12:43, Stephen Farrell wrote:

Thanks for your feedback, Stephen.

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?

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.
> is one of the three options not mandatory-to-implement?

The current [un-published] version makes pub-sub MTI.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 May 2016 23:11:44 +0100

Hi Joe,

Those are all fine changes. Couple of tweaks suggested below.

> 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

Your call. So long as it's there somewhere I think we're sorted.
And the rest below is fine.

Cheers,
S.

---

From: [email-masked]
Date: Wed, 4 May 2016 19:20:07 -0400

Sent from my iPhone

> On May 4, 2016, at 6:11 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Joe,
> 

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

---

From: Joe Clarke <[email-masked]>
Date: Fri, 6 May 2016 16:28:10 -0400

> 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.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 May 2016 21:31:28 +0100

> .  We believe they satisfy your discuss items.

Yep, post that and I'll clear,
Cheers,
S.

---

From: Joe Clarke <[email-masked]>
Date: Fri, 13 May 2016 11:36:36 -0400

> Yep, post that and I'll clear,

We just posted rev -10 of the draft.  Thanks for the review and text, 
Stephen.

Joe