Subject: [perpass] draft-davin-eesst

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 2 Jan 2014 18:06:59 +0000

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.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 4 Jan 2014 00:01:56 +0000

On Jan 3, 2014, at 2:43 PM, Chuck Davin <[email-masked]> 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:

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

---

From: Chuck Davin <[email-masked]>
Date: Fri, 03 Jan 2014 17:43:09 -0500

Hi Fred,

Nice to hear from a once familiar face.  

Your questions are very much to the point.

Your scope question is "why so narrow a description?"  A brief answer
is that the specified format targets a particular application.  At
some point, the generality of onion-layered infrastructure must give
way to the particularity of doing some actual real-world task.  In
this case, the OpenPGP standard is applied to provide exactly the
services for which it is designed.  While OpenPGP services could
certainly also be applied in other application domains (e.g., your
example of electronic health records (EHR)), the two applications are
really quite different in terms of audience, requirements, etc.  My
guess is that the superficial commonality between them is not enough
that distilling it would greatly simplify the solution to either
problem.

Your protocol question is "why spend so much time on the structure of
the email message?"  The answer is that we want interoperable
applications.  If a student is applying for a job at a small
commercial enterprise, then his transcript will likely be received as
a normal email message, validated using a normal email reader, and the
PDF component will be reviewed by a human.  However, if our student
has applied to Big University, then the defined format supports
automated validation of the received transcript and automated
extraction of the transcript content (XML) into an Admissions
Department database.  Automation is important, because the Internet,
common application, and other factors have dramatically changed
college admissions, so that even smaller institutions can receive
surprisingly large numbers of applications.  Naturally, we want
transcript recipients to be as tolerant as possible of how students
convey their transcript information, and the spec is perhaps not so
restrictive as it sounds, but application implementors also
need guidance about how hard they should try to unpack a received
message before kicking it to a human.

Your first security concern relates to the optional use of encryption
by students in sending their transcripts to recipients.  For me, you
have certainly struck at the "heart of the matter."  I confess that,
in earlier versions, the encryption was mandatory.  Arguments for
relaxing the encryption requirement are, first, international students
may not always have easy access to encryption, and, second, that
encryption may sometimes be beyond the technical reach of Mom-N-Pop
enterprises.  But either of these limitations could be overcome by, for
example, burning a transcript onto a CD-ROM disk and sending it via
postal mail.  Thus, I vacillate frequently on the question of mandatory
encryption.  However, I do not fully share your concern about students
who decline to encrypt owing to the poor usability of email encryption
tools.  One can imagine a trivial, very application-specific script
that students could use to send their transcripts to chosen
recipients.

The information is "at rest" only when held by the originator, the
student, or the recipient, but they are all authorized users.  What
remains are attacks upon their hosts.  Thus, the "at rest" question
seems close to the question of whether or not one should encrypt one's
files when not logged in, a question with an easy answer (yes!) but a
bit beyond the scope of the draft.  Of course, the "at rest" threat is
yet another reason to require encryption when the student transmits his
transcript, so perhaps the scale should be tilting much more that way.

The "MTA transit" problem also argues for mandatory encryption of
student transmissions.  But there are alternate approaches as well.
The Internet is supposed to be end-to-end.  Thus, the MTA transit risk
could be mitigated by enabling end-to-end email connections between
student and recipient, who could operate a specialized server that
welcomes arbitrary SMTP connections.  Insofar as the balkanization of
our email infrastructure had been largely a response to spam, individual
sites could, if they wish, choose to prefer built-in end-to-end security
over the convenience of reduced spam.

Best,
Chuck

---

From: Chuck Davin <[email-masked]>
Date: Tue, 07 Jan 2014 05:45:47 -0500

Hi Fred,

Thanks for clarifying.  Whatever the terminology, your point is well
made that end-to-end encryption is probably the only sufficient
protection.

I haven't quite yet given up on privacy or basic human rights, even for
students.  Better to light a candle and all that.

Stay warm,
Chuck