RE: [TLS] RFC 2817 proposed standard status revocation?

Benjamin: Lets distinguish our work in IETF, from having fun in R&D, discussion opensource forums (e.g. ssl-talk, where the community worked on SSL3, outside the bounds of formal standardization rules).

If I shorten the argument that follows to a few words, alluding to Steve Kent's infamous paper on stack-based networking:- are we putting things at the right layer?

-------------

Within an IETF WG structure, operating under modern rules:

1. I have not called for TLS to be removed from the standards track: only for the WG to perhaps "stop"...and let what we have become the standard. 10 years is quite long enough, given precious little of the core has changed in those 10 years, and we have been through 4 versions already. I don't expect to see this recommendation adopted, tho, knowing well those who operate the IETF Security Area. Arguably, the horizontalization of TLS via the IETF-era activities into (1) the EAP arena, (2) into non-PKI ciphersuites, (3) SAML extensions, (4) and even into HTTP1.1 Update , are all worthwhile per se, and more such value could be expected to be forthcoming from this WG.

2. I have also called into question whether several new work items (proposed in memo form, and more properly in I-D form) are really worthy of extending the life of the WG, arguing against my own "close now, while we are ahead" proposal. These issues are far more debatable, and go to the heart of the question: so what is the role of TLS in the Internet Security Architecture - noting that the designers intended it merely to be an IPSEC stopgap. It was not their intent, however, to provide all that IPSEC would provide. Concerning Today, not yesterday, should the communities intent really be to address DoS, non-repudiation, client id protection? Or, should we be encouraging application to use migrate to an enhanced IPSEC world, for these capabilities?

3. I have certainly called for RFC 2817 to be withdrawn from the standards track - a personal opinion that 2817's model of HTTP1.1/TLS handling of client-id protection and TLS-bridging is inappropriate, 5 years after publication and upon reflection with what is actually going on today. This is mainly on the grounds that vendor systems applying https, as we have known it since 1994, have simply NOT followed IESG's 2817-based lead to migrate AWAY FROM https, even in the web world. A standard that has little adoption is worthless, and perhaps ought not to continue life in the standards track. It can go in the FYI pile. At the same time, lets reflect that it was an example of an IETF WG following an earlier IESG-architectural MANDATE/RESOLUTION - to work to move the Internet away from the TLS setup practices of https, and its ilk. The world didn't buy this, tho - despite the MANDATE.

Now, all of these comments address standards issues, with a technical focus. We could perpetuate our WG life for ever, designing yet more and more cute TLS features. But lets take into account that something far more important occurred in Vista, than making TLS the default https (RFC2818-styled) provider (albeit 2818-compliance is only apparent in InternetExplorer/control URL handling, apparently): IPv6 is provided, and the full IPSEC architecture is now soon likely to become much viable than the IPv4 world restricted its role to be, so far. As a community with the wider IETF interests at heart, I assume, we surely don't want to do in TLS WG what we really ought to be doing by refining the IPSEC family of protocols?

As someone who berated IPSEC technology and adoption rates for years (Yea! Go SSL! Its simple! And, it works well, today!) I'm leading the debate, in light of what is happening: perhaps its time to move on from the former positions I took during the stopgap period - where the only goal was GET ADOPTION, by any and all means. Perhaps we need to reflect think what the fuller community's interests needs really are, FOR THE FORMAL ISSUANCE OF INTERNET STANDARD STATUS to TLS-related RFCs: given IPv6 (and therefore IPSEC) infrastructure maturity levels are improving at a smart click. 

Perhaps I really ought to express this in the security area forum, not TLS WG?

> Date: Sun, 10 Dec 2006 14:37:52 -0800> From: ben@layer8.net> To: home_pw@msn.com> CC: tls@lists.ietf.org> Subject: Re: [TLS] RFC 2817 proposed standard status revocation?> > -----BEGIN PGP SIGNED MESSAGE-----> Hash: SHA1> > Peter,> > While TLS may be objectionable to you based on engineering elegance> grounds, the fact remains that it is widely adopted and Some People> prefer it _in practice_ to IPSec. One could apply similar logic to> yours to argue for elimination of TCP in favor of SCTP as the "distinct> layer smushing" you lament is in full flower in that somewhat successful> old protocol. I'm not holding my breath for that to happen, even if> everyone agreed it was a Good Idea, and I look forward to many more> years of getting enormous value from TLS.> > > bb> > > Peter Williams wrote:> > > > > > 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.> > > > > > -----BEGIN PGP SIGNATURE-----> Version: GnuPG v1.4.4 (Darwin)> > iD8DBQFFfIxANGhGGgVakhcRAqqSAKDYrlB65jFAYc/So1xnaxp5DPPKhgCgrs6h> GNeoyJ+URGYlGTySiAEjY7A=> =ML1R> -----END PGP SIGNATURE-----
_________________________________________________________________
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