[Cryptography] The role of the IETF in security of the Internet: for or against the NSA? for or against the security of users of the net?

[Jerry Leichter]

On Jul 20, 2014, at 1:16 PM, Miles Fidelman <mfidelman at meetinghouse.net> wrote:
>>> A trustworthy system is one that you *can* trust; a trusted system is one
>>> that you *have* to trust.
>> 
> Well, if we change the words a little, the government world has always made the distinction between:
> - certification (tested), and,
> - accreditation (formally approved)
The words really are the problem.  While "trustworthy" is pretty unambiguous, "trusted" is widely used to meant two different things:  We've placed trust in it in the past (and continue to do so), for whatever reasons; or as a synonym for trustworthy.  The ambiguity is present even in English, and grows from the inherent difficulty of knowing whether trust is properly placed:  "He's a trusted friend" (i.e., he's trustworthy); "I was devastated when my trusted friend cheated me" (I guess he was never trustworthy to begin with).

In security lingo, we use "trusted system" as a noun phrase - one that was unlikely to arise in earlier discourse - with the *meaning* that the system is trustworthy.

Bruce Schneier has quoted a definition from some contact in the spook world:  A trusted system (or, presumably, person) is one that can break your security.  What's interesting about this definition is that it's like an operational definition in physics:  It completely removes elements about belief and certification and motivation and focuses solely on capability.  This is an essential aspect that we don't usually capture.

When normal English words fail to capture technical distinctions adequately, the typical response is to develop a technical vocabulary that *does* capture the distinctions.  Sometimes the technical vocabulary simply re-purposes common existing English words; sometimes it either makes up its own words, or uses obscure real words - or perhaps words from a different language.  The former leads to no end of problems for those who are not in the field - consider "work" or "energy" in physics.  The latter causes those not in the field to believe those in it are being deliberately obscurantist.  But for those actually in the field, once consensus is reached, either approach works fine.

The security field is one where precise definitions are *essential*.  Often, the hardest part in developing some particular secure property is pinning down precisely what the property *is*!  We haven't done that for the notions surrounding "trust", where, to summarize, we have at least three:

1.  A property of a sub-system a containing system assumes as part of its design process ("trusted");
2.  A property the sub-system *actually provides* ("trustworthy").
3.  A property of a sub-system which, if not attained, causes actual security problems in the containing system (spook definition of "trusted").

As far as I can see, none of these imply any of the others.  The distinction between 1 and 3 roughly parallels a distinction in software engineering between problems in the way code is written, and problems that can actually cause externally visible failures.  BTW, the software engineering community hasn't quite settled on distinct technical words for these either - bugs versus faults versus errors versus latent faults versus whatever.  To this day, careful papers will define these terms up front, since everyone uses them differently.

                                                        -- Jerry