Re: [perpass] draft-davin-eesst

["Fred Baker (fred)" <[e-mail]>]

On Jan 3, 2014, at 2:43 PM, Chuck Davin <[e-mail]> wrote:
> I may not have completely understood your second security concern.  It
> seems to relate to the vulnerability of student information either at
> rest or in transit across MTAs.  To me, these seem like different
> cases.
> 
> The information is "at rest" only when held by the originator, the
> student, or the recipient, but they are all authorized users.  

In that, I will disagree, or will ask you to accept two variants of "at rest". I'm using the term in the sense of having the entire transmission in one place in the application layer and a choice of what to do with it, as opposed to looking at it at the network layer or lower and simply passing the trash. 

Ask yourself, for example, what an Ironport or Barracuda Spam Barrier is; to my mind, it is an MTA that analyzes an email message and applies a policy to it. In some defined set of cases, it might observe that the message comes from a common business partner and is therefore likely to be OK, and passes it like any other MTA might. In another set of cases, it might summarily discard the message, and in a third set of cases, it might simply hold it, or it might redirect it to somewhere else for further processing. In determining whether an email is viral, it might ask whether users receiving the message are marking it junk, and might as a result search for it in a held database and "junk" it. And it might look through attachments for recognizable patterns of malware.

If a MIME object is encrypted, it is harder to poke through for malware structures. Other analyses, such as looking for common names of objects carried in MIME, can still be done. So for most of the purposes relevant to pervasive monitoring, at least to my small mind, it is at rest.

But we agree that in the two MUAs, it is at rest. I will argue that it will spend most of its life at rest in the databases of at least some of the institutions. My concern there is with the integrity and privacy of the data itself.

Walking off into another world, consider automated billing such as is intended to be done in the smart grid. These are records that will have to be reproduced and proven valid in the event of a billing dispute, and therefore must be retained. However, not everyone is authorized to have access to the data in the same form. The billing agent needs access that will support billing, which may include how many KWH were transferred at each of several billing rates. The electrical utility itself needs aggregate information for planning purposes. The homeowner, at least in California, is supposed to be able to access their own data in real time (for some definition of that term) in a manner that allows them to evaluate changes they make to their homes. And a their that has access to the billing or real-time data might use it as a way to remotely case a break-in target. Data at rest becomes a means not only for legitimate and authorized behavior, but inappropriate and unauthorized behavior.

Data at rest in the medical world is notoriously used to investigate medical conditions that an insurer would like to not have to cover. Data at rest is sought by others for various purposes. Target recently had a problem with its POS systems that captured credentials for some 40M credit card accounts. 

So yes, while the risks are probably not as high with high school transcripts, I think the same fundamental issue is in play. I'm concerned about the transcript five years after the institution has received it. I'd like a hacker to not be able to gain access to its contents.

> Your closing paragraph seems to sketch an alternative approach to the
> MTA transit problem (??) or other "casual access."  I took its gist to
> be that, absent student encryption, the originator could control
> access to the student data using the originator's encryption keys.  In
> common with other centralized approaches, it is, as you say, "not
> perfect security."  In particular, the student is not really in control
> of her own data.

Well, I would submit that the student is still not in control of their own data. Once they give it to someone else, that someone can give it to an additional party without the student's knowledge. And the level of limits that can be placed on that are pretty low; the student could encrypt it in the public key of the institution s/he sends it to, meaning that only that person or institution can open it, but once decrypted, it is in the clear and can be saved and transferred. So while I support the goal, I think it has limits.

> I undertook this work less to innovate and more to address a real
> world problem.  Although, to this community, the posted draft should
> seem pedestrian, to a broader audience, it clearly demonstrates that
> large centralized databases are not the only technical option for
> addressing school transcript distribution.  The centralized approach
> permits students little real privacy and no real control over
> distribution of their own personal information.  In contrast, the
> common format and distributed approach in the posting assign protocol
> roles to the various players that are appropriate to their proper
> rights and responsibilities.  Review, support, and implementation
> within this community would counter the claim that a more
> paternalistic, centralized approach is the only one that is
> technically feasible.

Ah, yes, I have enrolled a kid in college as well, and has to specify the set of schools that the student's transcripts would be sent to. I get this. That said, what I suggested (that each institution have a public key and distribute the keys to each other in some way) is only centralized if you consider hkp://wwwkeys.pgp.net and its friends a centralized server.

> Thanks for your very thoughtful review and comments.
> 
> Best,
> Chuck
> 
> On Thu, 2014-01-02 at 18:06 +0000, Fred Baker (fred) wrote:
>> I scanned quickly through draft-davin-eesst with a few basic puzzlements in mind. The mechanism makes sense. I have two questions on security/privacy considerations, one on the protocol involved, and one on scope. I am copying perpass, because I suspect that my considerations have bearing on the broader topic of pervasive monitoring of traffic.
>> 
>> If I understand correctly, the EESST specification is intended to facilitate the secure transmission of data private to one party but originated by a second party to a set of third parties with legitimate and authorized interest. The specific case is a secondary school transcript, being sent by a student, originated by an institution, and received by a set of other institutions; the data is, of course, private to the the student, who is presumably applying to the receiving institutions. 
>> 
>> My question on scope is: "why so narrow a description?" I can think of other cases in which data private to one party and originated by a second party is sent to a set of third parties with legitimate and authorized interest; medical records come quickly to mind. I could imagine the basic mechanism being described in generic terms and the transmission of transcripts described separately as a use case for the mechanism. 
>> 
>> My protocol question is "why spend so much time on the structure of the email message?" If the student has the files, they could be communicated via http upload, IM, USB key, twitter, or any other application. Even if email is used, the student is likely to simply attach them to an email message using his or her favorite email tool without regard to the specifics of the EESST specification. In any case, the transmission will need context: unless s/he is uploading them to an application web page at the receiving institution (which is its own context), the student will likely include either text or another file as a cover letter. Why not simply say that the files are exchanged without reference to the protocol in question?
>> 
>> But now to what I consider the heart of the matter. 
>> 
>> The specification calls for a pair of files (XML and PDF) to be signed by the originating institution, for purposes of authenticity and integrity checking, and for the MIME object containing it to be optionally encrypted, so that it cannot be inspected in an MTA. I understand that encryption being optional, in that few mail tools make S/MIME or OpenPGP easy enough for a non-expert to use - even in the IETF, few have PGP keys, and since our lists don't have keys, even this email is being sent in the clear. So the call for encryption is largely vacuous, and the very real possibility remains for inspection of data while at rest in an MTA or captured in flight on a traffic analyzer. Due to our failure to provide simple key creation and management tools, this private and important data is accessible to a casual eye in flight.
>> 
>> However, in the use case, the transcript is likely to survive as a record for years, and perhaps forever, but only be in transit for a period of seconds to minutes in the usual case. The specification leaves the data at rest unencrypted, available for casual inspection. One could argue that this is not an issue with a transcript; nobody is going to lose their job over having gotten a bad grade decades earlier. In the medical record use case, it can have dramatic effects. I think the primary threat is unauthorized or inappropriate access/use when the data is at rest. 
>> 
>> Why not have the originating institution encrypt the data using its private key and make that key available to other institutions? In this or another specification, you could give them a naming guideline that would identify the file as pertaining to an individual and an institution, and therefore a specified public key. This is not perfect security, of course; an unauthorized party that obtained the public key of the originating institution could read the file. But it at least forces them to do so, as opposed to leaving the data open to hack or casual access.
> 
> 

	• Make things as simple as possible, but not simpler.
Albert Einstein