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 On Sat, 2014-01-04 at 00:01 +0000, Fred Baker (fred) wrote: > On Jan 3, 2014, at 2:43 PM, Chuck Davin <[email protected]> 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 > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
