W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

RE: security requirements

From: Paul Leach <paulle@windows.microsoft.com>
Date: Fri, 20 Oct 2006 10:59:11 -0700
Message-ID: <76323E9F0A911944A4E9225FACFC55BA02810439@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
To: Robert Sayre <sayrer@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>

IMO, the biggest threat is that vendors ship implementations that simply
_can't_ be configured to interoperate. The MTI rule tries to prevent
that. The only "enforcement" mechanism is that vendors can't morally
claim conformance unless they obey.

Once an implementation is in customers' hands, there's nothing to
prevent them from configuring it so that it doesn't interoperate. That's
essentially what is behind the threat of which you speak, and I don't
see any technical solution. However, availability of an acceptable MTI
mechanism at least means that such customers have no excuse for
non-interoperability. That's why I think the MTI rule addresses the more
fundamental threat.

-----Original Message-----
From: Robert Sayre [mailto:sayrer@gmail.com] 
Subject: Re: security requirements

But since the rules concern
implementations rather than deployments, MTI doesn't prevent the
actual threat to HTTP interoperability: centralized authentication
services. It's a backwards rule intended for companies shipping
routers and floppy discs. Web applications can route around it.

--

Robert Sayre
Received on Friday, 20 October 2006 17:58:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:53 GMT