[TLS] RFC 2817 proposed standard status revocation?

I assume this WG is, or would be, responsible for handling RFC2817 standards track issues?http://tools.ietf.org/html/rfc2817.

I record my recommendation that the cited document have its PROPOSED STANDARD status revoked. Period. Its bad (SSL) theory, and even worse practice.

I understand from the text what Rohit was aiming for, and why; but its the wrong tack. The HTTP 1.1 update profile for SSL should not be attempting as an INTERNET STANDARD to be a universal upper-layer stack protocol: using A-bridges everywhere, smushing what the distinct layers do, adding A-layer multiplexing for IP-addressed endpoints, and mis-purposing SSL's stack-oriented security model. 

Subsequent to that RFC 2817 era, ws-security and soap have essentially re-invented what ISO's upper-layer-security and ROSE/RTS/Presentation/Session protocols used to attempt to do, for open networks. The modern web services architecture does use the SSL security architecture properly, however - and will thus easily move to the (competing) IPSEC security architecture ...once IPv6 gets ubiquitous.

Never ever forget, SSL was intended as an IPSEC stopgap. In IETF, dont force TLS into a long term position in the internet security architecture that it doesn't deserve (e.g. RFC2817). It is SUPPOSED to go away, at some point.

From: home_pw@msn.comTo: pgut001@cs.auckland.ac.nz; mike-list@pobox.com; tls@lists.ietf.orgSubject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLSDate: Sun, 10 Dec 2006 09:57:07 -0800

sounds more like they are using some or parts of the "SSL Handshake" (parts of which are now known as a "client protocols" of the TLS record layer, in a very dubious architectural move by IETF :-) given the SSL "privacy" goal) as a replacement for IKE, within the IPSEC architecture.  I.E. there may be no TLS Record layer, in openVPN's application context ? I can see why this will get the DARPA-funded folks in IETF jumping up and down, with rage; its dumps the (US-dominated) oakley compromises. I don't believe this (i.e. merely) was an intended modality of the SSL patent, but _not_ inconsistent with the open-ness intended. N&S-derived handshakes for accessing network authentication servers have been around a fair while! I remember reading the article on the Cambridge design, when I was at school (20 years ago)! WS-SX's SecureConversation is following the same course as OpenVPN we can note, however. They are paying careful attention paid to how T-bridges can be handled, each with different security policies concerning how handshakes are selected, the crypto module is seeded etc. It updates and nicely extends much of the unspecified/unstandardized work done in SSL Connect proxy land, with a strong focus on (a) multiple key management domains for each bridge segment, and (b) ensuring connectionless transports are properly handled (c) initiator/respondent access point roaming, and auto-rekeying of the cascade of T-bridge segments... upon roam of either endpoint (GSM security model, styled)  

> From: pgut001@cs.auckland.ac.nz> To: home_pw@msn.com; mike-list@pobox.com; tls@lists.ietf.org> Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS> Date: Mon, 11 Dec 2006 06:11:21 +1300> > Peter Williams <home_pw@msn.com> writes:> > >"OpenVPN actually runs TLS over UDP byimplementing a reliability layer for> >the TLS control channel. TLS is a fairlystrong, well regarded protocol,> >easily accessible using the OpenSSL library,and it seems to be the obvious> >choice for initial authentication and keyexchange. "> >http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00263.html> > In a nutshell what OpenVPN does is use TLS for the handshake and IPsec's ESP> for the UDP transport.> > >Is this still true? I'm proud of the designers who did this, if its true.> >They "got it' > > They certainly did. Throw away IKE and AH, and what's left of IPsec (ESP) is> actually pretty decent - they took the bits that worked and glued them> together to get... well, something else that works.> > Unfortunately the result is completely unpalatable to the IPsec folks, and> probably not too palatable for the TLS side either.> > Peter.

Search from any Web page with powerful protection. Get the FREE Windows Live Toolbar Today! Try it now! 
_________________________________________________________________
All-in-one security and maintenance for your PC.  Get a free 90-day trial!
http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=wl_wlmail