Subject: RE: [TLS] draft-housley-evidence-extns-00.txt

From: "Peter Williams" <[email-masked]>
Date: Fri, 1 Sep 2006 09:12:45 -0700

A very, very, very long time ago, ssl-talk discussed for weeks whether SSL supported, could support, or even should support evidentiary services such as non-repudiation - i.e. whether some of its protocol exchanges might be used at the application level to support claims at layer 7, generated as a side-effect of using the comms. stack. We focused on applying the blurring to the problem of enforcing UK/US mandatory key escrow policies - a high-priority topic for IESG, at that time.
 
For example: if one initiated a second SSL3 handshake mid-session without dropping the https session context, one inherently created evidence related to the data exchanged between the two SSL2/SSL3 message-layer handshakes. That second handshake was evidence of the data exchange pattern at the https level. 
 
We even defined parallel handshakes, using the SSL3 message layer's allowance for defining custom handshake flows, that did things like mandatory key escrow deposit and then policy *Enforcement* (which was popular at the time and perhaps this is back to popularity in 2006 IETF?) to showoff applicability of one handshake to express control over the https session ongoings on the primary channel. (This would ensure the server that the mandatory rules had been enforced on the consumer https channel, otherwise the server would drop the https session to comply with govt policies etc). I even remember writing up an proof, using inductive logic, for the mandatory integrity properties.
 
Now, the list seems to be badly failing to distinguish between https and its socket-layer security protocol support. 
 
Another way of saying that is, however - perhaps time had come to revist what we were saying in 1995 when we even then wondering about blurring the distinctions, between the stack layers - as regard to evidence generation from a socket provider. Are we thus truly "failing", or are we simply changing the paradigm, finally!
 
While there was always interplay in the SSL design world between what happened in the application (the https realm known to the Netscape 2 browser hypermedia platform) and the SSL layer (behind the socket in winsock), we were clear that app vs layer separation was to be clean. For example, certs chains were processed by the https-layer application process in accord with the hypermedia experience of sessions focusing on session identity(s)  and confidence policy(s) thereto, but core SSL handshakes and security context session resumption processes were handled by the kernel/winsock provider without regard to "secure interworking pattern" being sought by the application context applying a socket provider's enhanced transport features.
 
Conclusion. I supported using SSL handshakes as evidence-generation purposes at the app layer in 1995. And, I therefore still do. It breaks all the design correctness rules, and lots of IETF dogma that motivated TLS's distinct conception of itself (vs SSL3). But.. so what! Dogma can always be rewritten.

> Date: Thu, 31 Aug 2006 11:39:36 -0400> To: [email-masked]> From: [email-masked]> Subject: Re: [TLS] draft-housley-evidence-extns-00.txt> CC: > > David:> > That is true, an application running on top of TLS could handle this > feature, but then every application would have to do so.  By putting > it into TLS, any application can easily be supported.  The alerts to > mark the beginning and end were intended to allow applications to > generate evidence for a portion of the application exchange, but > these can be sent at the beginning and the at end of the TLS session > to support arbitrary applications.> > Russ> > > At 09:01 PM 8/30/2006, David Hopwood wrote:> >Russ Housley wrote:> > > http://www.ietf.org/internet-drafts/draft-housley-evidence-extns-00.txt> > >> > > I would like the TLS WG to be aware of this document.  Review is> > > encouraged, and comments are welcome.> >> >What is the rationale for complicating TLS with this, when it seems as> >though it could just as easily be supported at the application protocol> >level?> >> >--> >David Hopwood <[email-masked]>> >> >> >> >_______________________________________________> >TLS mailing list> >[email-masked]> >https://www1.ietf.org/mailman/listinfo/tls> > > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Express yourself with gadgets on Windows Live Spaces
http://discoverspaces.live.com?source=hmtag1&loc=us

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