RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend)

[Peter Williams <[e-mail]>]

We have the good basis of liaison here, as we did so successfully (ultimately) obtain in the PKI world;
a informal partnership between ABA-ISC and IETF. 
 
But the onus is wrong, so far, in the compromise. There is just no point outsiders arguing anything in 
IETF: its a cult mentality during design, and is very fearful of change, once the torturous 
"commenting" process comes out with a consensus lest it be lost. IETF quickly enter reactionary mode 
of reasoning, as we have seen; out comes the Chenytank, to publicly dunk folk in!
 
Marc's research is, in Peter's analysis, founded on NCSC Red Book doctrine - partitioned N-TCBs and 
multi-level enforcement. We don't openly engineer using those design precepts, in IETF - tho most if not 
all of our senior engineers are Very well versed in it, and its associated trust modelling. Many of IETF 
"staff" engineer are or have been funded by folks who ultimately assume and often religiously enforce 
this *kind* of design indoctrination, furthermore.  Red Book precepts don't go down well everywhere, 
even in the UK security community, military of otherwise, mostly for similar religious reasons. (They have 
their own equivalent doctrinal models, religiously imposed.) 
 
But, caveats aside! http://www.windowsecurity.com/whitepaper/rainbow_series/ 
see Red Book, part B.
 
I happen to like the Red Book's TNI, as the spirit of its author(s) comes through. I'm an independent, 
particularly in the USG internal doctrinal wars between DoD/NSA, DARPA, GSA -- and DHS these days. 
Part B was/is a very USEFUL conceptual framework (being a _technical rationale_), even if Part A is very 
dated. And, its purely technical (allowing for its doctrinal biases, and its tendency to meander around 
the old political issues of the day). If we now point to the two main terms Marc uses: TLS Authorization, 
and TLS Evidence, we can perhaps map these onto TNI doctrine. And we have not strayed into legalisms, 
yet! We are still firmly in IETFland: albeit circa 1987!
 
While designed as an evaluation model for making reasoned conclusions about network systems, from trusted 
components, its  also a useful design tool. (Using the mental framework of the auditor at design-time, always 
makes passing tests at audit-time easier!), And it provides "Specific  guidelines  for  actually partitioning the 
various network policy elements to [trusted] components "
 
If we simply quote the guts of this 1987 view of the networking world, founded (in the TNI doctrine) on 
TNI's "access control concept" : we can see that 
 
     Using the definitions  provided  above,  the  followingconclusion  may be stated: if it is supposed (1) that a sub-ject is confined to a single component throughout its  life-time,  (2)  that  it may directly access only objects withinits component, (3) that every component contains a componentreference  monitor  that  mediates all accesses made locally(and enforce the same access control policy), and  (4)  thatall   communications  channels  linking  components  do  notcompromise the security  of  the  information  entrusted  tothem,  one  may  conclude  that the total collection of com-ponent reference monitors is a  reference  monitor  for  thenetwork.   
 
TLS Authorization maps to the confinement objective. TLS evidence maps to the "data" given to the 
(partitioned) reference monitor to allow (or not allow) "non-local" access, subject to the (MAC/DAC) algebra 
in the selected enforcement model for access control. TLS itself of course maps onto the
Communication channel, where its the key management (certs/labels/trusted stacks) of the 
SAs/TLSConnections that now "distributes" the access control concept across the partitions of the 
trusted net, whilst using PKI/crypto/TLSHandshakes/FIPSboxes to enforce centralized policy at 
all those edges.
 
What worries me about the research is the politics endgame. I'm not sure I *want* IETF to 
standardize the use of partitioned access control concepts - in order to create an infrastructure 
that enforces the local vs non-local separation. For local and non-local, one can read national vs
transnational/bilateral.
 
At the same time, if we step into the legal domain, for a moment, there is no  internet law. There is 
only a collection of national laws (ignoring the specialized non-representative international law regime), 
and one necessarily steps from local law to non-local law, even with the internal political
structures of the US or the EU!
 
So, before we accept charter modification, we have to develop an understanding
of the endgame. Then, the liaisons can be placed on a sound footing. Lots
of tortuous and tortious commenting would surely happen, a few dunkings would no doubt 
occur, and you never know, like PKI, another miracle COULD happen allowing
law and technology to converge to cause even an IETF security protocol to become willingly
adopted into the mainstream of society.
 
The timing is right for this issue to be raised.
 
Peter.
 
 
 
 
 



> From: [e-mail]> To: [e-mail]; [e-mail]> Date: Thu, 21 Dec 2006 12:47:45 +0000> Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend)> CC: > > Mark,> > > Thanks for your helpful comments. I don't agree entirely with you,> > specifically your position that signatures are (must be?) application> > level constructs> > I don't think I ever said that. I said that evidence is formed in an application context.> > > Would the TLS WG be willing to extend the> > charter for evidence even if a large part of the discussion was hosted> > by a lawyer community and could take some time to hash out?> >> > My vote is NO.> > The legal and technical side of this can and must be separated. If the legal side wants to present some requirements for security properties, fine. But a security protocol must be defined on technical grounds for the security properties it brings. The technical community in IETF is quite capable of that. It is not capable of determining what a lawyers will accept or not accept in the hundreds of legal systems around this globe.> > I agree with Ari, this protocol has potential, but only if we can isolate it to the technical discussion.> > > Stefan Santesson> Senior Program Manager> Windows Security, Standards> > > > -----Original Message-----> > From: Mark Brown [mailto:[e-mail]]> > Sent: den 20 december 2006 18:20> > To: [e-mail]> > Cc: Stefan Santesson; 'EKR'> > Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00> > (resend)> >> > Stefan, (resend, to [e-mail], with additions to the first> > paragraph)> >> > Thanks for your helpful comments. I don't agree entirely with you,> > specifically your position that signatures are (must be?) application> > level> > constructs, but you're probably in the majority on this issue. My> > opinion> > is based on personal experience though. I am working on a router> > project> > that uses TLS Evidence and Authorizations at the TLS level only:> >> > http://www.navysbir.com/06_1/215.htm> >> > The router works below the application-level and aims at high assurance> > under Common Criteria, e.g. EAL6. Its design and implementation has> > been> > and will continue to be carefully scrutinized. This project does not> > depend> > on "signer's intent" though, and perhaps intent is what you locate at> > the> > application level?> >> > I think you're right about this: the wisest choice may be to wait and> > see> > how things pan out in the legal community, and not try to extract a> > final> > answer from them too soon. Would the TLS WG be willing to extend the> > charter for evidence even if a large part of the discussion was hosted> > by a> > lawyer community and could take some time to hash out?> >> > For those of you who are interested in the legal aspect of "evidence",> > I am> > currently engaged in conversation with the American Bar Association's> > Information Security Committee listserv. If you would like to enter> > that> > discussion, please let me know.> >> > The ABA ISC discussion has recently rehashed the use of the term> > "evidence"> > with respect to TLS Evidence. To summarize that discussion as fairly> > as I> > can, I think as long as one spells evidence with a lowercase "e" and> > not as> > Evidence or EVIDENCE the lawyers on the ISC listserv are comfortable> > with> > the term. I also plan to work closely with the ABA Digital Evidence> > Project> > over the next year as well, and my first project with DEP is to hash> > out> > terms together.> >> > The following is a snippet -- really, a teaser -- for those of you with> > some> > inclination to join the ABA ISC group:> >> > (mark)> > > The TLS definition of "evidence" is unstated to allow it to flex with> > the> > > prevailing> > > definition in the legal world (this decade's definition or the> > next's).> > >> > > You say the definition of evidence is anything that can be "thrown> > into> > > the> > > pot", which seems reasonable to me.> > >> > (Steven Teppler)> > > > First, what is unknown is the definition of "evidence" as the> > technical> > > > protocol means it. In the legal world, anything can be, and> > usually> > > > thrown> > > > into the pot as, evidence. How is this specie of evidence> > different> > > from> > > > other evidence?> > >> > (mark)> > > TLS Evidence does not claim some special privilege e.g. being> > > non-repudiable. It's just evidence like everything else in the pot.> > The> > > specter of duress is never eliminated, for example. How could it be?> > > Neither does TLS Evidence claim any special privileges to magically> > gain> > > affirmatives to any of the following:> > >> > (Steven Teppler)> > > > Is EG'd evidence automatically admissible? Does it> > > > automatically exclude contradictory digital data or testimony?> > Does it> > > > generate enough evidence to survive a summary judgment motion?> > Does it> > > > satisfy a burden of production? Burden of persuasion? If so, why> > isn't> > > > some modifier, such as "trusted evidence" or "summary judgment> > > eliminator"> > > > used?> > >> > (mark)> > > No thank you! If a court chose to admit TLS Evidence into a trial> > then> > > that> > > court could examine it as a record like anything else. The TLS> > Evidence> > > draft standard _only_ defines a minimum technical standard for> > security> > > measures including cryptographic/equality tests which must be passed> > > before TLS Evidence is "born".> >> > Best regards,> >> > mark> > > _______________________________________________> TLS mailing list> [e-mail]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Get into the holiday spirit, chat with Santa on Messenger.
http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=en-us

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls