Subject: [mile] RFC6045-bis, update per ITU comments and list discussions

From: <[email-masked]>
Date: Fri, 19 Aug 2011 12:38:18 -0400

Hello,

The attached is an updated version of RFC6045 (RFC6045-bis) which is up for determination in the ITU-T in two weeks.  As a result, of the ITU-T determination, the document needs to move to standards track and a -bis version is required.  The ITU has requested text changes since the document will be translated into a number of other languages, those changes are reflected in this version.  Additional textual changes may be made over the next two weeks through their review process.

A few changes to RID have been made per comments on this list and I would like to get opinions on how they are addressed in the attached, specifically on the changes outlined below:

"LawEnforcement" was added as a RIDPolicy option in text and in schema.  This was added as a result of some on and off-list discussions as the option is relevant today for Law enforcement that already accepts incidents in an IODEF format.  IODEF is required in Japan when sending incidents to law enforcement.

Through Dr. Katherine Goodier and Gaus (Damir Rajnovic) work on the privacy and data marking extension, they determined stricter guidance was needed for encryption options.  Guidance has been added to the Security section for XML encryption using the already defined IODEF:restriction attribute.  The text is as follows for ease of review:

________
Security, XML encryption section:
 o  The iodef:restriction attribute sets expectations for the privacy
      of an incident and is defined in section 3.2 of RFC5070.  The
      restriction attribute can be set in any of the RID classes to
      define restrictions for the complete exchange of an IODEF document
      (including any extensions) or within specific classes of IODEF or
      IODEF extensions where more limited restrictions are desired.  The
      restriction attribute is contained in each of the RID classes and
      MUST be used in accordance with privacy expectations for either
      sections of the IODEF document or the complete IODEF document.
      Consortiums and organizations should consider this guidance when
      creating exchange policies.
   o  Expectations based on restriction setting:
      *  If restriction is set to "private", the class or document MUST
         be encrypted for the recipient using XML encryption and the
         public key of the recipient.
      *  If restriction is set to "need-to-know", the class or document
         MUST be encrypted to ensure only those with need-to-know access
         can decrypt the data.  The document can either be encrypted for
         each individual for which access is intended or a single group
         key may be used.  A group key in this instance refers to a
         single key (symmetric) that is used to encrypt the block of
         data.  The users with need-to-know access privileges may be
         given access to the shared key by distributing or providing
         access to it encrypted with each of their public keys.
      *  If restriction is set to "public", the class or document MUST
         be sent in clear text.  This setting can be critical if certain
         sections of a document or an entire document are to be shared
         without restrictions.  This provides flexibility within an
         incident to share out certain information freely where
         appropriate.
      *  If restriction is set to "default", The information can be
         shared according to an information disclosure policy pre-
         arranged by the communicating parties.
   o  Expectations based on placement of the restriction setting:
      *  If restriction is set within one of the RID classes, the
         restriction applies to the entire IODEF document.
      *  If restriction is set within individual IODEF classes, the
         restriction applies to the specific IODEF class and the
         children of that class.
_________

Since incidents may not be network-centric and may still have a use case where the information received is not directly from the originator, the digital signature on the IP packet may need an alternate option for verifying the source.  I am proposing the use of EventData where each party that adds to the event data would provide a detached digital signature.  Another option (not in the document) would be to include a default IP packet, bit I think that could be confusing.  The text is as follows:

________
Security, XML Digital Signature Section:
o  If an Investigation request does not include an IP packet, the
      EventData class instance from each the parties involved in the
      investigation MUST be signed using a detached signature.  The
      EventData class can be used to extend information about an
      incident by each CSIRT or SP involved in the investigation.  Using
      this class for the digital signature when an IP Packet is not
      included provides a method to verify each party contributing to
      the details of the incident.
_________

Sections removed:
1.3, Attack Types and RID Messaging,
Section 2, RID Integration with Network Provider Technologies
3 Characteristics of an Attack and subsections - should this be in an appendix or where it was in the document?
Section on RID Communication flow removed text as it was not relevant to the
heading, may need to be moved to subsections if content is not addressed
already

Some sections were re-ordered, I will go back to update section references in the next version.

Thank you in advance!

Kathleen

---

From: <[email-masked]>
Date: Tue, 23 Aug 2011 12:41:51 -0400

Hi Kathleen,

> "LawEnforcement" was added as a RIDPolicy option in text and in schema.  This was added as a result of
> some on and off-list discussions as the option is relevant today for Law enforcement that already
> accepts incidents in an IODEF format.  IODEF is required in Japan when sending incidents to law
> enforcement.

That seems very general in isolation, as there are a lot of law enforcement agencies.
Is a single ENUM value sufficient, or is it useful to distinguish regional, national
and/or other law enforcement bodies?

At a minimum, it would be useful to include a reminder that use of "LawEnforcement" does
not remove the requirement to additionally use "AcrossNationalBoundaries" when the later
also applies.

-- XML Digital Signature

This text is not clear to me:

>       investigation MUST be signed using a detached signature.

Is that one signature covering all the EventData from every party involved, or is each
party supposed to supply a signature for the EventData contributed by that party?  I
suspect the latter was intended (e.g., as I have no idea why Alice should be signing
event data from Bob that she can't independently verify), so some rephrasing is
probably in order.

-- XML Encryption

I'm somewhat concerned that the new XML Encryption text is requiring use of keys without
saying anything about key distribution or management.  While mandating specific key
distribution and/or management protocols would be overly restrictive, it would be good
to provide some guidance on what needs to be done for some level of assurance that the
encryption is done with the correct key and the intended recipient(s) (but not other
parties) will be able to decrypt the result. For example:

(1) "private" uses a public key of the recipient. How does the sender verify the binding
of the public key to the recipient's identity? A discussion of how to use a certificate to
do that (e.g., where's the recipient's identity in the RID/IODEF XML, how is it supposed to
match which field in the certificate) with a suitable PKIX RFC reference would be helpful.
A reminder to check for revocation (e.g., of the certificate) before using a public key
would also be good.

(2) "need-to-know" allows use of a group-shared symmetric encryption key that is somehow
distributed to the recipients.  That's potentially dangerous if not carefully controlled,
and as this is the "Security Considerations" section, some security considerations for that
distribution are probably in order, starting with a warning that she who has the symmetric
key can decrypt, making control of that key vital to confidentiality of the need-to-know
information.  Is there a straightforward way to optionally handle key distribution in the
IODEF/RID document (e.g., an XML section that contains the symmetric key encrypted with
each of the intended recipients' public keys)? 

The "Characteristics of an Attack" material might be usefully recast as guidance for use
of RID, which could be an appendix.

Something to keep in mind when editing the next version is that this version has a mix
of IETF requirements key words (MUST/SHOULD/MAY) and non-IETF requirements key works
(shall/should/may) - picking one set would probably be better, and if ITU requires use
of the latter, an explanation that maps them to their IETF counterparts would be good.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, August 19, 2011 12:38 PM
> To: [email-masked]
> Subject: [mile] RFC6045-bis, update per ITU comments and list discussions
> 
> Hello,
> 
> The attached is an updated version of RFC6045 (RFC6045-bis) which is up for determination in the ITU-T
> in two weeks.  As a result, of the ITU-T determination, the document needs to move to standards track
> and a -bis version is required.  The ITU has requested text changes since the document will be
> translated into a number of other languages, those changes are reflected in this version.  Additional
> textual changes may be made over the next two weeks through their review process.
> 
> A few changes to RID have been made per comments on this list and I would like to get opinions on how
> they are addressed in the attached, specifically on the changes outlined below:
> 
> "LawEnforcement" was added as a RIDPolicy option in text and in schema.  This was added as a result of
> some on and off-list discussions as the option is relevant today for Law enforcement that already
> accepts incidents in an IODEF format.  IODEF is required in Japan when sending incidents to law
> enforcement.
> 
> Through Dr. Katherine Goodier and Gaus (Damir Rajnovic) work on the privacy and data marking
> extension, they determined stricter guidance was needed for encryption options.  Guidance has been
> added to the Security section for X ML encryption using the already defined IODEF:restriction
> attribute.  The text is as follows for ease of review:
> 
> ________
> Since incidents may not be network-centric and may still have a use case where the information
> received is not directly from the originator, the digital signature on the IP packet may need an
> alternate option for verifying the source.  I am proposing the use of EventData where each party that
> adds to the event data would provide a detached digital signature.  Another option (not in the
> document) would be to include a default IP packet, bit I think that could be confusing.  The text is
> as follows:
> 
> ________

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 05:30:37 -0400

Hello David,

Thank you for your comments.  Questions for the list are indented.

I would like more opinions on a few of the questions raised.  In particular, for those that share documents with law enforcement, do we need multiple options?  This could be used in combination with the TrafficType option of "OfficialBusiness", but does not specify if the government entity is local, regional, national, etc.

      Should we include one option of LawEnforcement as the entities sending/receiving the RID message
      would know what type of LawEnforcement agency in which the message is being exchanged.  Or do others
      on the list who exchange incident information think it would be helpful to have multiple enumerated values
      to represent the types of agencies.  The values for the second option could be "LawEnforcement-local", 
      "LawEnforcement-regional", and "LawEnforcement-national".  If the incident documents are forwarded from
      one type of law enforcement agency to another, digital signatures on the additions from each group would
      provide the traceability of any new information.

I added the following to the description of the "LawEnforcement" enumeration per David's suggestion:
"If the law enforcement agency resides within a different nation that the sending entity, the "AcrossNationalBoundaries" enumeration MUST also be set."

XML Encryption:

Thank you for pointing out the need for clarification on the new text.  The intent is the same as if the IPPacket were to be used for the signature where only the text entered by an entity would be signed by that entity.  

      Would the additional sentence (2nd sentence) provide enough clarification for this intention:

"If an Investigation request does not include an IP packet, the EventData class instance from each the parties involved in the investigation MUST be signed using a detached signature.  The signature MUST only be applied to the data entered or added from each entity to provide a method of authentication on the work added by any party involved in the investigation.  The EventData class can be used to extend information about an incident by each CSIRT or SP involved in the investigation.  Using this class for the digital signature when an IP Packet is not included provides a method to verify each party contributing to the details of the incident."

XML Encryption:

I will provide additional information on the use of PKI, but will do this through pointers to existing standards like RFC5280.  If there are updates to PKI, we should build in the flexibility to leverage updates to those specifications.  RFC5280 covers path validation (verify the chain of the certificate and status) so that one is able to verify the CA that signed a certificate and also check a revocation list.  

As for key distribution, this is outside of IODEF and RID.  I will be sure to add additional text to provide references on recommendations for these functions.  The security of the key distribution process and the levels of trust for PKI would be based on policies agreed between entities.

The identity of entities in the IODEF document are in the contact class.  

For the use of a group key, I will be sure to reference the appropriate standards.  Again in this case, policy sets the agreed upon handling of keys between entities.  There may be entities that do not require as high a level of trust as other sets of entities or consortiums.  I will be sure to include references to policies/agreements to set the appropriate levels of trust.

I will develop text to address the questions raised in this section and send them to the list for review.

Thank you for the opinion on characteristics of an attack.  I will add this text back in, but will need to be careful to ensure other attack ties like social engineering are represented in this section as the use cases for IODEF has expanded and will continue to expand with the addition of the proposed extensions for MILE.

Thanks for the note on SHALL versus MUST.  I forgot to mention that I will use the SHALL and other ITU-T preferred key words for the ITU-T while formalizing the document over the next week+ in this forum.  One the text is formalized here with considerations for translating into multiple languages, I will update the text in RFC6045-bis to match, but will use the IETF key words, MUST, etc.

Thank you,
Kathleen
________________________________________
From: Black, David
Sent: Tuesday, August 23, 2011 12:41 PM
To: Moriarty, Kathleen; [email-masked]
Subject: RE: RFC6045-bis, update per ITU comments and list discussions

Hi Kathleen,

-- XML Digital Signature

-- XML Encryption

Thanks,
--David

---

From: Brian Trammell <[email-masked]>
Date: Wed, 24 Aug 2011 11:57:53 +0200

hi, Kathleen,

A couple of points, inline.

Cheers, Brian

>      provide the traceability of any new information.

I'm not sure we want to get into taxonomizing law enforcement agencies. 

The local/regional/national is almost general enough for a lot of cases, but it does tend to project an American-style arrangement of the agencies onto the situation. "Local" and "Regional" agencies have very different powers even among states; the situation is less and less recognizably layered according to the American model the further you are from America. Kantonspolizei Zürich, to take an example off the top of my head, is a local-sized, regional-level LEO with a territory comparable in size of that covered by the NYPD, but with one tenth the officers, which lists national border control as one of its competencies. Italian national-level police forces have potentially overlapping jurisdictions WRT incident handling, so "national" might not give you additional information. And even trying to _determine_ the relationships among LEOs in some countries is a job for (national-level) intelligence agencies and/or graduate-level work in international relations.

The agency will be identified in the RID message, correct? This should provide enough information for the sender/receiver to make choices to data handling without resorting to an incomplete taxonomy, I think...

> "If the law enforcement agency resides within a different nation that the sending entity, the "AcrossNationalBoundaries" enumeration MUST also be set."

I would generalize this to "across jurisdictional boundaries," though I am not exactly certain how. For example, EU organizations in countries implementing EU data protection directives are more free to exchange data with each other than with organizations outside (and this in and of itself is subject to exceptions, cf. "EU safe harbor" provisions, or operational exceptions for network security information). So, data could cross the German/Austrian border, for example, but be subject to far less restriction than crossing the German/American border.

> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 24 Aug 2011 12:09:48 +0200

I'd suggest that anything related to this subject be
kept as generic as possible.  The capabilities being
supported are subject concurrently to many different
legal requirements that are global, regional, national,
sub-national, and local in nature.  The authorities involved
consist of a great many kinds of government agencies,
including officers of a court in the case of eDiscovery and
other kinds of civil proceedings.

The ETSI global eWarrant standards work ultimately
allowed for multiple generic terms for its interface,
as depicted in the diagram below.  You should consider
the possibility of using only "authority."

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 06:24:40 -0400

Thank you Brian and Tony for the comments on the use of LawEnforement.  It seems from these comments, we should use only one indicator for this field, if others agree/disagree, please post to the list.

Tony suggests the use of "Authority".  Is this more appropriate than "LawEnforcement"?

Also, Brian raised another question on an enumeration that is in RFC6045 in RIDPolicy.  Should "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundaries" or some other indicator for this marker?

I also agree that the contact information will be provided, so I think using a more generic marker is appropriate.  Is there agreement/disagreement on this point?

Next for the handling of data between countries where you get into privacy considerations, safe harbor, etc.  I believe this will be handled in the extension on data markings from Dr. Katherine Goodier and Gaus Rajnovic.  They should be able to match up any markers with guidance on how to set the IODEF:restriction appropriately for the various markers used so that encryption can be appropriately used at the RID layer with the new guidance.  Could Katherine and/or Gaus confirm?

I had a little time and wrote up text to address the PKI questions from David and will send those out a little later.

Thank you!
Kathleen

________________________________________
From: Tony Rutkowski [[email-masked]]
Sent: Wednesday, August 24, 2011 6:09 AM
To: Brian Trammell
Cc: Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussions

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 10:08:14 -0400

Hi Kathleen,

I have a use case question about your suggested text:

> "If the law enforcement agency resides within a different nation that the sending entity, the
> "AcrossNationalBoundaries" enumeration MUST also be set."

How does iteration among cooperating law enforcement agencies work?

To build on Brian's example, suppose the Kantonspolizei Zürich sends the incident to one of the Italian national police forces, who in turn sends the incident onward to the US FBI.  Among the entity that originated the incident report, and these two EU-resident law enforcement agencies, which one is responsible for ensuring compliance with EU data protection/privacy requirements and setting the appropriate enumeration value to indicate that this has been done?

A plausible answer is that the entity that sends the data outside the EU shall do this (one of the Italian national police forces in the example), and the upstream entities should (may?) do this if they have reason to believe that the incident handling is likely to cross EU boundaries (e.g., trace identifies a source in a US block of IP addresses) and scrubbing the data early in the incident handling will not compromise handling effectiveness.

I think some of this is covered in the draft - "7.6.  Privacy Concerns and System Use Guidelines," e.g., the paragraph that begins with "Intra-consortium RID communications raise additional issues, especially when the peering consortiums reside in different regions or nations", but that doesn't seem to cover law enforcement agencies.

Beyond this, I think Brian's commentary suggests that a single jurisdictional ENUM value is insufficient:

> I would generalize this to "across jurisdictional boundaries," though I am not exactly certain how.
> For example, EU organizations in countries implementing EU data protection directives are more free to
> exchange data with each other than with organizations outside (and this in and of itself is subject to
> exceptions, cf. "EU safe harbor" provisions, or operational exceptions for network security
> information). So, data could cross the German/Austrian border, for example, but be subject to far less
> restriction than crossing the German/American border.

It appears that a value is needed that unambiguously indicates that the incident data complies with requirements for leaving the EU (without use of an exception), e.g., such a value would assist the German authorities in demonstrating incident handling system compliance in an EU data protection/privacy audit.  Beyond that, the German authorities may need another value to differentiate data that must stay within Germany (or even the German agency handling the data) vs. can be sent to Austria - that value would not promise compliance with data requirements for leaving the EU.

Unfortunately, this is starting to look like an invitation to a tar pit, as values are likely to be needed for a plethora of national data protection/privacy laws and regulations.  IMHO, IANA is not a good place to maintain a registry of data protection/privacy laws and regulations.  Is some other entity already doing this in a fashion that can be pointed to?

Thanks,
--David

> Sent: Wednesday, August 24, 2011 6:25 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Thank you Brian and Tony for the comments on the use of LawEnforement.  It seems from these comments,
> we should use only one indicator for this field, if others agree/disagree, please post to the list.
> 
> Also, Brian raised another question on an enumeration that is in RFC6045 in RIDPolicy.  Should
> "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundaries" or some other indicator for
> this marker?
> 
> I also agree that the contact information will be provided, so I think using a more generic marker is
> appropriate.  Is there agreement/disagreement on this point?
> 
> Next for the handling of data between countries where you get into privacy considerations, safe
> harbor, etc.  I believe this will be handled in the extension on data markings from Dr. Katherine
> Goodier and Gaus Rajnovic.  They should be able to match up any markers with guidance on how to set
> the IODEF:restriction appropriately for the various markers used so that encryption can be
> appropriately used at the RID layer with the new guidance.  Could Katherine and/or Gaus confirm?
> 
> I would generalize this to "across jurisdictional boundaries," though I am not exactly certain how.
> For example, EU organizations in countries implementing EU data protection directives are more free to
> exchange data with each other than with organizations outside (and this in and of itself is subject to
> exceptions, cf. "EU safe harbor" provisions, or operational exceptions for network security
> information). So, data could cross the German/Austrian border, for example, but be subject to far less
> restriction than crossing the German/American border.
> 
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 24 Aug 2011 16:33:15 +0200

Hi, David, all,

I'm sadly not aware of an effort to catalog these; this may have something to do with the fact that the details get murkier (of course!). Even within the EU, for example, just implementing 95/46/EC (data protection) doesn't necessarily mean you're allowed to re-forward data, or even to forward data in the first place, as the member states are free to implement the directive in any way in which they see fit, and one state may be more restrictive than another. My personal preference in this area would be for a URI for a document that explains the restriction in lawyer-readable terms, but then you need a consortium to maintain that...

Information sharing among law enforcement agencies is even trickier, and rather outside my expertise.

On this point, we're getting into data markings territory. 

One thing to note is that the use cases for operational RID and LE-RID are rather different; except in exceptional circumstances (and for their own networks), LEOs generally do not have operational responsibility for traffic flows, and I'm not aware of any LEO that steps in on behalf of a network operator to order another to do something (this seems in the US anyway like it would require the intervention of a court, in any event). So LEOs aren't really going to be involved in anything interactive; this is more for reporting incidents after or well after the fact. So the big, scary, complicated multijurisdictional forwarding use cases would seem to be vanishingly rare; the more common case is "I am company X, I got hacked by gangsters Y, you are the Z State Police, and according to regulation I have to send you this incident report in a format you can read so my insurance company will pay me for the costs of resetting everyone's password."

Not that the other case isn't interesting; I just think we can avoid overthinking things by stepping back and asking what a proposed mechanism is really going to be used for...

Cheers,

Brian

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 10:36:36 -0400

Hi Brian,

I'm fine with declaring law enforcement iteration scenarios as out-of-scope, although Kathleen should probably add a sentence or two to state that.

Thanks,
--David

> From: Brian Trammell [mailto:[email-masked]]
> Sent: Wednesday, August 24, 2011 10:33 AM
> To: Black, David
> Subject: Re: [mile] LawEnforcement and jurisdiction
> 
> Hi, David, all,
> 
> I'm sadly not aware of an effort to catalog these; this may have something to do with the fact that
> the details get murkier (of course!). Even within the EU, for example, just implementing 95/46/EC
> (data protection) doesn't necessarily mean you're allowed to re-forward data, or even to forward data
> in the first place, as the member states are free to implement the directive in any way in which they
> see fit, and one state may be more restrictive than another. My personal preference in this area would
> be for a URI for a document that explains the restriction in lawyer-readable terms, but then you need
> a consortium to maintain that...
> 
> One thing to note is that the use cases for operational RID and LE-RID are rather different; except in
> exceptional circumstances (and for their own networks), LEOs generally do not have operational
> responsibility for traffic flows, and I'm not aware of any LEO that steps in on behalf of a network
> operator to order another to do something (this seems in the US anyway like it would require the
> intervention of a court, in any event). So LEOs aren't really going to be involved in anything
> interactive; this is more for reporting incidents after or well after the fact. So the big, scary,
> complicated multijurisdictional forwarding use cases would seem to be vanishingly rare; the more
> common case is "I am company X, I got hacked by gangsters Y, you are the Z State Police, and according
> to regulation I have to send you this incident report in a format you can read so my insurance company
> will pay me for the costs of resetting everyone's password."
> 
> Not that the other case isn't interesting; I just think we can avoid overthinking things by stepping
> back and asking what a proposed mechanism is really going to be used for...
> 
> Cheers,
> 
> Brian
> 
> > To build on Brian's example, suppose the Kantonspolizei Zürich sends the incident to one of the
> Italian national police forces, who in turn sends the incident onward to the US FBI.  Among the entity
> that originated the incident report, and these two EU-resident law enforcement agencies, which one is
> responsible for ensuring compliance with EU data protection/privacy requirements and setting the
> appropriate enumeration value to indicate that this has been done?
> >
> > A plausible answer is that the entity that sends the data outside the EU shall do this (one of the
> Italian national police forces in the example), and the upstream entities should (may?) do this if
> they have reason to believe that the incident handling is likely to cross EU boundaries (e.g., trace
> identifies a source in a US block of IP addresses) and scrubbing the data early in the incident
> handling will not compromise handling effectiveness.
> >
> > I think some of this is covered in the draft - "7.6.  Privacy Concerns and System Use Guidelines,"
> e.g., the paragraph that begins with "Intra-consortium RID communications raise additional issues,
> especially when the peering consortiums reside in different regions or nations", but that doesn't seem
> to cover law enforcement agencies.
> >
> > It appears that a value is needed that unambiguously indicates that the incident data complies with
> requirements for leaving the EU (without use of an exception), e.g., such a value would assist the
> German authorities in demonstrating incident handling system compliance in an EU data
> protection/privacy audit.  Beyond that, the German authorities may need another value to differentiate
> data that must stay within Germany (or even the German agency handling the data) vs. can be sent to
> Austria - that value would not promise compliance with data requirements for leaving the EU.
> >
> > Unfortunately, this is starting to look like an invitation to a tar pit, as values are likely to be
> needed for a plethora of national data protection/privacy laws and regulations.  IMHO, IANA is not a
> good place to maintain a registry of data protection/privacy laws and regulations.  Is some other
> entity already doing this in a fashion that can be pointed to?
> >
> > Thanks,
> > --David
> >
> >
> >> I had a little time and wrote up text to address the PKI questions from David and will send those
> out
> >> a little later.
> >>
> >> Thank you!
> >> Kathleen
> >>

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 10:59:24 -0400

Hello David,

Thank you for the additional comments.

Iteration would be handled through the same method as other instances of iteration with updated contacts and the appropriate use of signatures for tracking, etc.  One LawEnforcement entity to another would be similar to a PeertoPeer,which is also not listed explicitly in this section as considerations are covered under other headings.

I believe the use cases being raised by both you and Brian fall into the area that will be addressed by the data classification/marking extensions that include privacy considerations by Dr. Katherine Goodier and Gaus Rajnovic.

At the start of the MILE list, there were three separate options proposed for handling markings and restrictions for data privacy laws of various countries.  The use cases you are referring to are specific to ones that contain privacy information as categorized by a country as the regulations are specific to personally identifiable information (PII).  This may not apply to all incidents that cross boarders of various countries.  If there is no PII (according to the definitions in the appropriate regulations - they vary slightly from one to another having read many of them), then there would not be any special handling considerations. 

If PII exists, then a marking would be used according to the extension to be developed specifications.  The option I like from the 3 previously proposed to the list was that you would list the country code (and state for the US) for the PII included in the incident.  From this, the appropriate considerations can be applied to the data according to the requirements of that country and where the data rests or s transferred to at the point of a decision.  The requirements are typically interpreted by the lawyers/compliance folks of the organization handing the data at the time (as they are responsible for mis-handling).  It would be important to have this handled at the SP (SP used generically as in RID-bis) sending the data as there may be new regulations that apply in some situations, like safe-harbour as data goes from Europe to the US for example as opposed to requirements that may be in place between nations in Europe.

I believe this is out-of-scope for RID, but the guidance may use options included in RID like the use of the IODEF:restriction attribute to require encryption.

Do others have opinions here?  Should guidance/markings come in the data classification/marking extension (may have a different name when published)?

Thank you,
Kathleen

________________________________________
From: Black, David
Sent: Wednesday, August 24, 2011 10:08 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: LawEnforcement and jurisdiction

Hi Kathleen,

Thanks,
--David

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 11:16:44 -0400

Kathleen,

> I believe this is out-of-scope for RID, but the guidance may use options included in RID like the use
> of the IODEF:restriction attribute to require encryption.

I believe that at least Brian, you and I are in violent agreement that this sort of law enforcement
iteration scenario is out-of-scope for core RID.

Thanks,
--David

> From: Moriarty, Kathleen
> Sent: Wednesday, August 24, 2011 10:59 AM
> To: Black, David
> Cc: [email-masked]
> Subject: RE: LawEnforcement and jurisdiction
> 
> Hello David,
> 
> Iteration would be handled through the same method as other instances of iteration with updated
> contacts and the appropriate use of signatures for tracking, etc.  One LawEnforcement entity to
> another would be similar to a PeertoPeer,which is also not listed explicitly in this section as
> considerations are covered under other headings.
> 
> I believe the use cases being raised by both you and Brian fall into the area that will be addressed
> by the data classification/marking extensions that include privacy considerations by Dr. Katherine
> Goodier and Gaus Rajnovic.
> 
> At the start of the MILE list, there were three separate options proposed for handling markings and
> restrictions for data privacy laws of various countries.  The use cases you are referring to are
> specific to ones that contain privacy information as categorized by a country as the regulations are
> specific to personally identifiable information (PII).  This may not apply to all incidents that cross
> boarders of various countries.  If there is no PII (according to the definitions in the appropriate
> regulations - they vary slightly from one to another having read many of them), then there would not
> be any special handling considerations.
> 
> If PII exists, then a marking would be used according to the extension to be developed specifications.
> The option I like from the 3 previously proposed to the list was that you would list the country code
> (and state for the US) for the PII included in the incident.  From this, the appropriate
> considerations can be applied to the data according to the requirements of that country and where the
> data rests or s transferred to at the point of a decision.  The requirements are typically interpreted
> by the lawyers/compliance folks of the organization handing the data at the time (as they are
> responsible for mis-handling).  It would be important to have this handled at the SP (SP used
> generically as in RID-bis) sending the data as there may be new regulations that apply in some
> situations, like safe-harbour as data goes from Europe to the US for example as opposed to
> requirements that may be in place between nations in Europe.
> 
> I believe this is out-of-scope for RID, but the guidance may use options included in RID like the use
> of the IODEF:restriction attribute to require encryption.
> 
> Do others have opinions here?  Should guidance/markings come in the data classification/marking
> extension (may have a different name when published)?
> 
> Thank you,
> Kathleen
>

---

From: Chris Inacio <[email-masked]>
Date: Wed, 31 Aug 2011 08:28:49 -0400

I have a quick thought exercise question related to PII.

IP addresses in the US are *not* PII.  IP addresses in the EU *are* PII.  

If an incident gets generated in the US, and it gets shared into the EU, what is the state of the IP addresses with regards to PII?

How does it change when:

we geolocate the IP addresses to both be in the US?
we geolocate an IP address to be in the EU?

If one address is in the US and one in the EU, when an EU entity wants to share information back to the US on the incident, do they have to drop the IP address?

I used IP addresses as a straw man, but it could be virtually any data element, right?

IETF defines protocols.  But to get the protocol right, we obviously need to understand how to use it.  I would argue a separate definition related to IODEF data types that can map jurisdiction & data type to handling requirements would be a good plan. Something that could inform on wether a datum is PII in jurisdiction or might be considered sensitive and require encryption, etc.

Thoughts?
Complaints?

Chris Inacio

---

From: <[email-masked]>
Date: Wed, 31 Aug 2011 11:49:48 -0500

I don't think I agree that any of this is in the scope of a transport protocol or exchange format. Recipients on either end are trusted to know what to do with different types of information when they process it; it sounds like what you're describing puts the workload of estimating recipient's sensitivity and privacy on the originator, which seems impossible to get consistently right, even if we could get every sovereign participant to submit their data sensitivity markings, rules and regulations with some form of centralized registry.

The US government is currently in the midst of a multi-year project just to try and identify and consolidate all the statutorily supported definitions of "sensitive but unclassified" information and consolidate guidance on how all those identified categories can be protected - and still none of it carries any weight with our national sunshine laws. We are chasing a moving target before we've even begun.

I truly believe the best (only?) engineering solution here is to provide the basics and punt the details to the implementers and their local requirements.

 - Tom Millar, US-CERT

[email-masked]
BB: [email-masked] / 202-631-1915
24x7: [email-masked] / 888-282-0870 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Inacio
Sent: Wednesday, August 31, 2011 8:29 AM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [mile] LawEnforcement and jurisdiction

How does it change when:

Thoughts?
Complaints?

Chris Inacio

On Aug 24, 2011, at 11:16 AM, <[email-masked]> <[email-masked]> wrote:

> Kathleen,
> 
>> I believe this is out-of-scope for RID, but the guidance may use 
>> options included in RID like the use of the IODEF:restriction attribute to require encryption.
> 
> I believe that at least Brian, you and I are in violent agreement that 
> this sort of law enforcement iteration scenario is out-of-scope for core RID.
> 
> Thanks,
> --David
> 
>> Iteration would be handled through the same method as other instances 
>> of iteration with updated contacts and the appropriate use of 
>> signatures for tracking, etc.  One LawEnforcement entity to another 
>> would be similar to a PeertoPeer,which is also not listed explicitly in this section as considerations are covered under other headings.
>> 
>> I believe the use cases being raised by both you and Brian fall into 
>> the area that will be addressed by the data classification/marking 
>> extensions that include privacy considerations by Dr. Katherine Goodier and Gaus Rajnovic.
>> 
>> At the start of the MILE list, there were three separate options 
>> proposed for handling markings and restrictions for data privacy laws 
>> of various countries.  The use cases you are referring to are 
>> specific to ones that contain privacy information as categorized by a 
>> country as the regulations are specific to personally identifiable 
>> information (PII).  This may not apply to all incidents that cross 
>> boarders of various countries.  If there is no PII (according to the definitions in the appropriate regulations - they vary slightly from one to another having read many of them), then there would not be any special handling considerations.
>> 
>> The option I like from the 3 previously proposed to the list was that 
>> you would list the country code (and state for the US) for the PII 
>> included in the incident.  From this, the appropriate considerations 
>> can be applied to the data according to the requirements of that 
>> country and where the data rests or s transferred to at the point of 
>> a decision.  The requirements are typically interpreted by the 
>> lawyers/compliance folks of the organization handing the data at the 
>> time (as they are responsible for mis-handling).  It would be 
>> important to have this handled at the SP (SP used generically as in RID-bis) sending the data as there may be new regulations that apply in some situations, like safe-harbour as data goes from Europe to the US for example as opposed to requirements that may be in place between nations in Europe.
>> 
>> I believe this is out-of-scope for RID, but the guidance may use 
>> options included in RID like the use of the IODEF:restriction attribute to require encryption.
>> 
>> Do others have opinions here?  Should guidance/markings come in the 
>> data classification/marking extension (may have a different name when published)?
>> 
>> Thank you,
>> Kathleen
>> 
>>> "If the law enforcement agency resides within a different nation 
>>> that the sending entity, the "AcrossNationalBoundaries" enumeration MUST also be set."
>> 
>> To build on Brian's example, suppose the Kantonspolizei Zürich sends 
>> the incident to one of the Italian national police forces, who in 
>> turn sends the incident onward to the US FBI.  Among the entity that 
>> originated the incident report, and these two EU-resident law 
>> enforcement agencies, which one is responsible for ensuring compliance with EU data protection/privacy requirements and setting the appropriate enumeration value to indicate that this has been done?
>> 
>> A plausible answer is that the entity that sends the data outside the 
>> EU shall do this (one of the Italian national police forces in the 
>> example), and the upstream entities should (may?) do this if they 
>> have reason to believe that the incident handling is likely to cross 
>> EU boundaries (e.g., trace identifies a source in a US block of IP addresses) and scrubbing the data early in the incident handling will not compromise handling effectiveness.
>> 
>> e.g., the paragraph that begins with "Intra-consortium RID 
>> communications raise additional issues, especially when the peering 
>> consortiums reside in different regions or nations", but that doesn't seem to cover law enforcement agencies.
>> 
>> Beyond this, I think Brian's commentary suggests that a single 
>> jurisdictional ENUM value is
>> insufficient:
>> 
>>> For example, EU organizations in countries implementing EU data 
>>> protection directives are more free
>> to
>>> exchange data with each other than with organizations outside (and 
>>> this in and of itself is subject
>> to
>>> exceptions, cf. "EU safe harbor" provisions, or operational 
>>> exceptions for network security information). So, data could cross 
>>> the German/Austrian border, for example, but be subject to far
>> less
>> It appears that a value is needed that unambiguously indicates that 
>> the incident data complies with requirements for leaving the EU 
>> (without use of an exception), e.g., such a value would assist the 
>> German authorities in demonstrating incident handling system 
>> compliance in an EU data protection/privacy audit.  Beyond that, the 
>> German authorities may need another value to differentiate data that must stay within Germany (or even the German agency handling the data) vs. can be sent to Austria - that value would not promise compliance with data requirements for leaving the EU.
>> 
>> Unfortunately, this is starting to look like an invitation to a tar 
>> pit, as values are likely to be needed for a plethora of national 
>> data protection/privacy laws and regulations.  IMHO, IANA is not a 
>> good place to maintain a registry of data protection/privacy laws and regulations.  Is some other entity already doing this in a fashion that can be pointed to?
>> 
>> Thanks,
>> --David
>> 
>> 
>>> Thank you Brian and Tony for the comments on the use of 
>>> LawEnforement.  It seems from these
>> comments,
>>> Also, Brian raised another question on an enumeration that is in 
>>> RFC6045 in RIDPolicy.  Should "AcrossNationalBoundaries" be changed 
>>> to "AcrossJuristictionalBoundaries" or some other indicator
>> for
>>> this marker?
>>> 
>>> I also agree that the contact information will be provided, so I 
>>> think using a more generic marker
>> is
>>> Next for the handling of data between countries where you get into 
>>> privacy considerations, safe harbor, etc.  I believe this will be 
>>> handled in the extension on data markings from Dr. Katherine Goodier 
>>> and Gaus Rajnovic.  They should be able to match up any markers with 
>>> guidance on how to set the IODEF:restriction appropriately for the various markers used so that encryption can be appropriately used at the RID layer with the new guidance.  Could Katherine and/or Gaus confirm?
>>> 
>>> I'd suggest that anything related to this subject be kept as generic 
>>> as possible.  The capabilities being supported are subject 
>>> concurrently to many different legal requirements that are global, 
>>> regional, national, sub-national, and local in nature.  The 
>>> authorities involved consist of a great many kinds of government 
>>> agencies, including officers of a court in the case of eDiscovery 
>>> and other kinds of civil proceedings.
>>> 
>>> The ETSI global eWarrant standards work ultimately allowed for 
>>> multiple generic terms for its interface, as depicted in the diagram 
>>> below.  You should consider the possibility of using only 
>>> "authority."
>>> 
>>> 
>>> 
>>> 
>>> 
>>> For example, EU organizations in countries implementing EU data 
>>> protection directives are more free
>> to
>>> exchange data with each other than with organizations outside (and 
>>> this in and of itself is subject
>> to
>>> exceptions, cf. "EU safe harbor" provisions, or operational 
>>> exceptions for network security information). So, data could cross 
>>> the German/Austrian border, for example, but be subject to far
>> less

---

From: <[email-masked]>
Date: Wed, 31 Aug 2011 12:55:24 -0400

I agree with Chris that we need to look at how a protocol is used to get it right.  The proposals so far are providing options that can be consistent in implementations, where policies (outside of implementations - but allow for options in implementations) may be applied to the options provided in the API or even in the applications.

As such, having options in IODEF and RID to enable actions to take place (like encryption of an entire document or section of a document or leaving out data elements) is required in the data format and the API (RID and Transport for RID).

Any more thoughts, agreements, disagreements?

Thank you,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Wednesday, August 31, 2011 12:49 PM
To: [email-masked]; Black, David
Cc: [email-masked]
Subject: Re: [mile] LawEnforcement and jurisdiction

 - Tom Millar, US-CERT

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Inacio
Sent: Wednesday, August 31, 2011 8:29 AM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [mile] LawEnforcement and jurisdiction

How does it change when:

Thoughts?
Complaints?

Chris Inacio