Subject: security requirements (was: Updating RFC 2617 (HTTP Digest) to use UTF-8)

From: "Robert Sayre" <[email-masked]>
Date: Tue, 17 Oct 2006 19:28:06 -0400

On 10/17/06, Lisa Dusseault <[email-masked]> wrote:
>
> Since there are so many ways to approach this, so many variations in
> what specs are revised and how they depend upon each other, I can't
> say whether I, or the IESG, expect a revision to RFC2616 to "step
> into" the area covered by RFC2617.

Perhaps we should poll the HTTP community as a start. Does anyone
think mandatory-to-implement security mechanisms will be helpful and
realistic?

-- 

Robert Sayre

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 18 Oct 2006 01:56:04 +0200

> think mandatory-to-implement security mechanisms will be helpful and

There's some interest in this area, fwiw:  
http://www.w3.org/Security/Activity

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 17 Oct 2006 20:08:47 -0400

> http://www.w3.org/Security/Activity

I'm aware of that effort, but I don't think it's relevant to the
question I asked.
Am I mistaken?

-- 

Robert Sayre

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 18 Oct 2006 02:35:09 +0200

>think mandatory-to-implement security mechanisms will be helpful and

Of course! Are you proposing to remove all the existing mandatory-to-
implement security mechanisms in RFC 2616 and RFC 2617?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 17 Oct 2006 20:38:15 -0400

> implement security mechanisms in RFC 2616 and RFC 2617?

Björn,

This is not a very helpful answer. Let me be more specific.

Does anyone think mandatory-to-implement authentication schemes or
transport-layer security mechanisms will be helpful and realistic?

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 18 Oct 2006 04:19:03 +0200

>transport-layer security mechanisms will be helpful and realistic?

That's still too broad. Should this be mandatory for servers, clients,
gateways, tunnels, proxies, protocols built on top of HTTP or their
clients or servers, application programming interfaces for any of these,
applications built on top of them, or maybe complex interactive user
agents, such as web browsers? Authentication what for? Access Control?
Logging? To what extend? Is an IP address a good enough identity? Or is
support for cookies good enough? Helpful in order to achieve what?

Should it be possible to make a software module that conforms to the
HTTP specification even though it does not implement any form of user
authentication or transport layer security? Yes, certainly. But that
does not imply that all software should be able to conform to it, or
derived specifications, without such support. There is a simple metric
here: a MUST-level requirement is reasonable only if you can argue that
any application to which the requirement applies is broken at a level
beyond "because the spec says it is", or in other words, only if it is
reasonable to expect any and all applications to meet the requirement,
assuming it applies to them.

There will typically be edge cases where you will have to decide that
it is better to use a SHOULD-level requirement, to encode the exceptions
as a condition for the MUST, or simply accept that some applications
will not conform to the specification, or that the specification does
not define conformance for that application at all. There are no hard
and fast rules here.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: David Morris <[email-masked]>
Date: Tue, 17 Oct 2006 18:50:58 -0700 (PDT)

> transport-layer security mechanisms will be helpful and realistic?

Yes ... w/o mandatory requirements there will be less availablity of
support for security features. Mandatory requirements mean a software
publisher can't claim compliance w/o implementing the feature. It is
easier to report defects in a claimed feature than it is to get a 'new'
feature implemented.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 17 Oct 2006 19:30:47 -0700

> transport-layer security mechanisms will be helpful and realistic?

Not without changing the HTTP version number, but I suppose that
I shouldn't assume that is obvious.  HTTP/1.1 has already been
deployed and I have no interest in declaring any of those
implementations broken just because they failed to anticipate a
not-yet-specified secure auth mechanism.  That ship has sailed.

So, if anyone thinks that a secure authentication scheme is a cool
thing, they should propose one and eventually update RFC 2617 to
include it, at which point it will be an OPTIONAL secure auth
mechanism for HTTP/1.1 (without any need to change RFC 2616).
The only way to make it a REQUIRED secure auth mechanism for HTTP
is to move on to HTTP/1.2, at which point we open the flood gates.

....Roy

---

From: Paul Leach <[email-masked]>
Date: Wed, 18 Oct 2006 02:43:44 +0000

One could argue that because so much of HTTP access is legitimately
anonymous, it should be OK for a conforming implementation to not have
to implement Basic or Digest. 

However, that doesn't mean that we couldn't spec it such that IF one or
more authentication mechanisms are implemented, that set must include
XXX (where XXX is the defined mandatory-to-implement auth mech).

I believe that MTI is a good idea, for the case where there is more than
one reasonable choice, in order to guarantee that all implementations
can be configured to interop.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Sayre
Sent: Tuesday, October 17, 2006 4:28 PM
To: Lisa Dusseault
Cc: Julian Reschke; [email-masked]; Larry Masinter; HTTP Working
Group
Subject: security requirements (was: Updating RFC 2617 (HTTP Digest) to
use UTF-8)

-- 

Robert Sayre

---

From: Robert Collins <[email-masked]>
Date: Wed, 18 Oct 2006 04:34:52 +0000

> transport-layer security mechanisms will be helpful and realistic? 

No: Lots of folk started offering HTTP/1.1 in their version line long
before they were even vaguely conformant, and new implementations still
show up with plenty of bugs (we ran into one just this month in fact).

I think that most existing implementations would just ignore it.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Oct 2006 10:17:12 +0200

> is to move on to HTTP/1.2, at which point we open the flood gates.

Thanks, Roy.

I think that makes it clear that a revision of HTTP/1.1 can't make that 
change, unless all existing implementations already comply to these new 
requirements (which they don't).

Best regards, Julian

---

From: Ingo Struck <[email-masked]>
Date: Wed, 18 Oct 2006 09:24:13 +0000

Robert, Roy,

> is to move on to HTTP/1.2, at which point we open the flood gates.
I would agree that it is in fact a bad idea to require
the implementation of any mandatory authentication scheme
within the core protocol definition.
There are applications where a server may want to implement
only the smallest subset of the protocol, remaining still
conforming but without the need for authentication (e.g.
high-performance static-content servers like a typical 
"image" or "media" server used and tuned to deliver high
volume static data).
This is what Paul Leach points out:
"so much of HTTP access is legitimately anonymous"

The strategy of making any authentication scheme optional
and moving the detailed specification out to a different
standards track seems to be quite an eligible feature of
http/1.1 and I consider it a major improvement over http/1.0
doing this.

From that point of view and imho the only viable way to
grind out interoperable and "acceptable" authentication
schemes would be to establish them apart from the core
protocol and "heal the wounds" of existing schemes (be
they widely deployed or not) in-place.

The only requirements that could be tied down to the core
protocol are things NOT to do, the most important being not
to use plain-text password transmission, thus dropping the
"compatibility to http/1.0" which is not near to being
considered as a standard anyway.
A formulation within an updated http/1.1 document could be
that a conforming server implementation MUST NOT use the 
Basic auth scheme (or equally weak schemes), while clients
MAY support it, but if they do they MUST warn the user
decidedly -- if this seems to be too restrictive a SHOULD NOT
could still suffice.

From a practical point of view this could be done, because
it is easy for a server implementation to drop an existing
feature. It should be done, because it poses an unacceptable
risk if used over unencrypted connections, which is quite
common habit.

As for rfc2617 I still consider it feasible to "fix" it in
the sense of replacing it with a document that tightens the
requirements, clarifies the ambiguous parts and drops the
unused or unusable parts while sticking to the mechanisms that
are widely implemented and could not be expected to be changed
without major updates of existing implementations.

Kind regards

Ingo Struck

---

From: Paul Leach <[email-masked]>
Date: Wed, 18 Oct 2006 07:47:44 +0000

Roy was right -- it's too late to make anything MTI in HTTP/1.1.

So, the question has to be whether it would make sense to make something
MTI in HTTP/1.2

Or, if we made a replacement for 2617, which offered several alternative
auth mechanisms, we could say that anyone who wanted to be compliant
with it had to implement one or more of said mechanisms. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Collins
Sent: Tuesday, October 17, 2006 9:35 PM
To: Robert Sayre
Cc: Bjoern Hoehrmann; HTTP Working Group
Subject: Re: security requirements (was: Updating RFC 2617 (HTTP Digest)
to use UTF-8)

-Rob

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 18 Oct 2006 12:19:09 +0200

> decidedly -- if this seems to be too restrictive a SHOULD NOT

I would add "without adequate transport level security" to the above.

Exchanges of plain-text passwords is often required for interoperability
reasons far beyond the HTTP protocol as such. In very many applications
the server simply MUST know the plain-text password of the user.

The main reason why Digest auth hasn't been widely deployed and most
still using Basic is because of these reasons. There is not very much as
such wrong with Digest auth even if there is areas which can be improved
(and many broken implementations), but in practice it's often completely
useless as the backend systems doesn't support Digest auth, only other
proprietary authentication protocols or plain text.

Quite recently there was a standardisation effort which have brought
Digest auth a bit closer to something deployable by extending RADIUS
with Digest auth support. Hopefully this will make Digest a more
available alternative.  

Regards
Henrik

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 18 Oct 2006 14:32:48 -0400

On 10/18/06, Julian Reschke <[email-masked]> wrote:
> > mechanism for HTTP/1.1
> change

I agree.

-- 

Robert Sayre

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Wed, 18 Oct 2006 17:08:35 -0700

If I may add a data point, the recently approved CalDAV states  
that a server MUST NOT implement Basic Auth or similar without SSL or  
similar.

   Personally, I think that sort of MUST NOT requirement is bogus,  
and fully intend to ignore it.  More specifically, I do no intend to  
disallow a server admin from configuring the server to allow Basic.   
My server's written in Python, and bypassing any such constraints  
would be trivial in any case.

   There will be zero CalDAV-compliant clients which will fail to  
interoperate with my server as a result of this, so as a practical  
matter, I have no incentive to comply with this requirement.

   It certainly won't be enabled by default, nor would I encourage  
such a config in a production environment, and I wouldn't put it in  
an admin UI.  But if a server admin decides that making Basic work is  
useful, then I'm not getting in the way.  I, for example, use it for  
testing, since SSL is a bit of a bother when using tcpflow.

   For what it's worth, as a client author I'd have a somewhat  
different viewpoint here.  But as a server author, SHOULD NOT makes  
plenty of sense, and MUST NOT strikes me as hard to justify.

	-wsv

---

From: Paul Leach <[email-masked]>
Date: Thu, 19 Oct 2006 01:11:14 +0000

A MUST NOT requiring that the default configuration not allow Basic auth (or equivalent) unless SSL (or equivalent) was in use would be more justifiable than a flat out prohibition.

However, I think even that is inappropriate _as a protocol requirement_ -- by the test that conformance isn't decidable by compliant implementations. In the "security considerations" section, however, it is permissible to make requirements that are not protocol requirements (e.g., don't store passwords in files accessible by ordinary users).

On the other hand, when there is a choice of authentication mechanisms defined for a protocol, and one or more of them is made "mandatory to implement", it is decidable whether the other party has done so. So I think that such requirements are a valid protocol "MUST".

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Oct 2006 09:01:53 +0200

> On the other hand, when there is a choice of authentication mechanisms defined for a protocol, and one or more of them is made "mandatory to implement", it is decidable whether the other party has…

Well, how do you decide that if the protocol implementation is a 
service, such as Google GData (please take this as just an example for 
the situation; I have no idea what they currently implement, and what 
they may in the future)?

In cases like these "not implemented" and "not deployed" can not be 
distinguished from the outside.

Best regards, Julian

---

From: Ingo Struck <[email-masked]>
Date: Thu, 19 Oct 2006 22:30:50 +0000

Wilfredo,

On Thursday 19 October 2006 00:08, you wrote:
> an admin UI.
That was the point of my admittedly drastic proposal -- 
to strongly disencourage the usage of this sort of things.

> different viewpoint here.  But as a server author,
Keep in mind that "as a server author" you have
to make best efforts to safeguard the needs of
your clients and the users thereof -- if you offer
something they use credulously without realizing
the negative impacts of using it you could be held
liable for that, at least your users could accuse you
of wanton negligence...
(My personal opinion, you might have a different position).

Kind regards

Ingo Struck

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Thu, 19 Oct 2006 15:16:32 -0700

Which is why I wouldn't think it wise to enable an unsafe  
configuration by default or to encourage such a thing.  But this is  
ultimately the call of the server administrator, and if they wish to  
configure the server to allow plain text over the wire, it's up to  
them, not me.

	-wsv

---

From: Larry Masinter <[email-masked]>
Date: Thu, 19 Oct 2006 21:45:07 +0000

I think if we're talking about mandatory-to-implement
security mechanisms, there actually seems to be some
activity on the topic at 

      http://www.w3.org/2006/WSC/

"Web Security Context Working Group

 From our charter: The mission of the Web Security Context
 Working Group is to specify a baseline set of security
 context information that should be accessible to Web users, 
 and practices for the secure and usable presentation of this 
 information, to enable users to come to a better understanding 
 of the context that they are operating in when making trust 
 decisions on the Web."

I would think that mandatory-to-implement security requirements
might depend on the application, and that there might be
a "mandatory-to-implement" policy for "web browsing"
that might not be "mandatory-to-implement" for all
applications of HTTP.

I wonder if the start of this discussion was
in response to "IESG response to the appeal by Robert Sayre"

http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03034.html

My understanding of BCPs and policies in general is that
they leave room for judgment.

In any case, appeals to IESG decisions should be made to
the IAB.

Larry

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 20 Oct 2006 03:50:45 -0400

On 10/19/06, Larry Masinter <[email-masked]> wrote:
> might depend on the application,

That doesn't make any sense to me.

> in response to "IESG response to the appeal by Robert Sayre"

No, that's the last data point.

> they leave room for judgment.

I agree. But the response is "this is the policy" when there are very
real practical problems with the policy. There needs to be a technical
discussion. Actually, it has happened, and the MTI people don't have a
leg to stand on, absent a pie-in-the-sky universal HTTP security
mechanism.

So far, I have found a disturbing tendency to lean on the documents.
My first attempt was to point out that the documents don't actually
support "the policy". Evidently, it is OK for IETF management to cite
normative folklore and then add clauses to whatever documents are in
front of them at the time to deal with an appeal. That's cool with
me--I will get consensus and rewrite the policy so there is no
arguing.

I think anyone entertaining an HTTP revision is a fool to do so
without a clear statement on security requirements. The last upgrade
HTTP security received was SSL, courtesy of Netscape Communications.

-- 

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Oct 2006 10:03:15 +0200

Robert Sayre schrieb:
> ...
> ...

Well, as Roy pointed out, a revision of HTTP/1.1 must not break 
implementations that comply to RFC2616. As RFC2616 doesn't have MTI 
security, this is it.

If the IESG doesn't allow a bug-fix revision of a standards track 
document for the reasons above, it really should stick to it's own rules 
(RFC2026), declare that spec as "historic", and - should the spec be of 
any importance - start an activity to define a successor specification. 
In general, the whole issue revising an IETF spec IMHO is very 
problematic; compare that with the W3C which has failed with XML 1.1, 
but at least maintains XML 1.0 properly (4th edition published in August).

Best regards, Julian

---

From: Paul Leach <[email-masked]>
Date: Fri, 20 Oct 2006 02:04:59 -0700

I don't think the IETF bashing is warranted. They made a mistake in not
requiring us to specify an MTI security mechanism in 2617 (and in having
2616 require that a conformant implementation support 2617). There was
no tacit agreement by some "in-crowd" that we didn't have to live by the
rules.

As I indicated in an earlier post, perhaps it was the prevalence of
legitimate anonymous access with HTTP that caused this oversight. Given
the to-do raised by Mr. Sayre recently, I doubt that anyone doing
HTTP/1.2 will have to worry about (or could count on) a similar
oversight :-)

Historically, the rules evolved because for a long time most protocol
designers totally ignored security -- throwing in plain-text passwords
at best. Hence the requirement to have non-plaintext-password
authentication, and security considerations sections. The notion of MTI
actually is totally independent of security -- it is a general principle
of protocol design for any protocol that has options, in order to
guarantee that conforming implementations can always be configured to
interoperate. (This was in reaction to the ISO protocol mess with
non-interoperable "profiles" of the 1980's.)

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 20 Oct 2006 11:23:33 +0200

Paul,

it's good to shed some light on the history and how it came all into  
being.

I think we all can agree that a suitable MTI security in HTTP would  
be a good thing. The problem is that current analysis by several  
people indicates that there is not such authentication scheme  
available right now. If it would, the debate could start which  
process to use in what spec and protocol revision that could best be  
incorporated.

But the current approach seems to talk about processes and barriers  
to spec revisions before that technical solution even has surfaced.  
Spec writers, putting often their spare time into this, feel  
frustrated. It seems that they either have to include some mumbo- 
jumbo into their spec which not everyone implementing the  spec is  
able to follow or shall fix the whole HTTP MTI security issue.

I feel this is wasting energy on both sides without giving any  
tangible results.

Cheers,

Stefan

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Oct 2006 12:11:24 +0200

Right Stefan.

To expand even further on that: requiring a MTI security mechanism for a 
theoretical HTTP/1.2 spec may be a good thing. Requiring it for a 
potential revision of HTTP/1.1 IMHO doesn't work, because today there is 
no common approach one could document; that is, a revision would break 
conforming implementations.

But Robert's complaint was triggered by the IESG asking for that kind of 
security mechanism for specs that just happen to *use* HTTP, such as 
AtomPub, CalDAV or XCAP. Those are applications of HTTP, not new protocols.

Best regards, Julian

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 20 Oct 2006 13:26:59 -0400

On 10/20/06, Paul Leach <[email-masked]> wrote:
>
> it is a general principle

Oh, I agree that there's certainly a judgement call for Working Groups
to make on this sort of thing. 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

---

From: Paul Leach <[email-masked]>
Date: Fri, 20 Oct 2006 10:59:11 -0700

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:[email-masked]] 
Subject: Re: security requirements

But since the rules concern

--

Robert Sayre

---

From: Paul Leach <[email-masked]>
Date: Fri, 20 Oct 2006 11:10:38 -0700

I don't get it. An application of HTTP could certainly say that a
conforming implementation has to be based on an implementation of HTTP
that supports Digest (for example). That should satisfy the MTI rule,
wouldn't it? This doesn't seem that hard, once the rules and the
motivation for them are understood.

Or, a new auth mechanism for HTTP could be created, and then the
application could make that mechanism mandatory. The downside would be
that not many conforming implementations would initially exist until the
new mechanism was widely deployed, but if the new mechanism had enough
value, then the fact that it was MTI for valuable HTTP application would
hasten its deployment.

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Friday, October 20, 2006 3:11 AM
To: HTTP Working Group
Cc: Paul Leach
Subject: Re: security requirements

security mechanism for specs that just happen to *use* HTTP, such as 
AtomPub, CalDAV or XCAP. Those are applications of HTTP, not new
protocols.

Best regards, Julian

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 20 Oct 2006 14:12:24 -0400

On 10/20/06, Paul Leach <[email-masked]> wrote:
> _can't_ be configured to interoperate.
>

Right, that's the conventional wisdom. Experience with HTTP shows that
server deployments drive clients to support as many HTTP security
mechanisms as they can. Undocumented mechanisms have been a problem.

HTTP security now takes place via forms, cookies, redirects, and
rubber bands. I think the IETF should create a bunch of new mechanisms
and see which one wins. Maybe there will be something to require in
2010.

> I don't see any technical solution.

Right.

-- 

Robert Sayre

---

From: Ingo Struck <[email-masked]>
Date: Fri, 20 Oct 2006 19:49:19 +0000

Robert,

> mechanisms as they can. Undocumented mechanisms have been a problem.
...and remain one.

> and see which one wins. Maybe there will be something to require in
I share this position. The current "rubber band" situation
is highly unsatisfactory and full of potential threats for those
using what is labelled "security" (emphasis on the quotation marks).

Imho one of the "bunch of new mechanisms" could be a re-written clean-up
of the existing ones (a well-done conforming rfc2617 Digest-auth MD5 
implementation can feature e.g. session-timeout, controlled log-off, 
one-shot nonces for requests with side-effects and the like).

Such a variant could have a good chance to be widely accepted soon
(because of existing implementations that could be made "fully" conforming
to the parts recognised to be viable very easily), while already providing
a security level that could be far superior over any of the innumerable
"rubber band" solutions.

Kind regards

Ingo Struck

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 20 Oct 2006 22:41:22 +0200

fre 2006-10-20 klockan 14:12 -0400 skrev Robert Sayre:

> rubber bands.

And to be honest mainly because web designers is not happy with how the
GUI (user-agents) presents the request for user credentials.

Regards
Henrik

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 20 Oct 2006 18:12:34 -0400

> And to be honest mainly because web designers is not happy with how the

That is one reason. The ad-hoc stuff can be more secure than the
standard schemes, too.

> GUI (user-agents) presents the request for user credentials.

Also, there is no logout button. I plan to take care of both problems
for new schemes in Mozilla.

Message body not displayed on HTTP 401 status response
<https://bugzilla.mozilla.org/show_bug.cgi?id=271383>

Need a markup widget to clear HTTP credentials
<https://bugzilla.mozilla.org/show_bug.cgi?id=355319>

Obviously, there will need to be buy-in from *all* of the big browser
vendors to move toward a Web standard. Maybe the W3C activity will
have that. If not, I don't see the point. Mozilla Foundation likes
standards when they result in one Web, so I doubt they will be a
holdout :)

-- 

Robert Sayre

---

From: Etan Wexler <[email-masked]>
Date: Sat, 21 Oct 2006 02:18:31 -0400

Paul Leach wrote to the mailing list of the former, and perhaps now 
nascent, HTTP Working Group:

> The only "enforcement" mechanism is that vendors can't morally

False advertising is illegal in some jurisdictions, so the matter is a 
matter of law and not only of morality. A matter of law is susceptible 
to action in the courts. Authorities of the state typically enforce the 
decisions of the courts. Therefore, given a certain amount of effort and 
talent, concerned parties can enlist the state as their enforcement 
mechanism.

---

From: David Morris <[email-masked]>
Date: Sat, 21 Oct 2006 09:42:37 -0700 (PDT)

I think for a claim to be considered false advertising, the claim
would have to be counter to a stronger specification mechanism than
the IETF. The IETF is an effective way to cooperate an produce working
standards, but those standards issued under the auspices of the IETF
have minimal legal standing. Enforcing the HTTP specification using
the courts would first require the standing of the standard.

Imagine trying to convince a court that one offender who didn't seem
to have a feature required by the standard should be punished should
be punished for false advertising when there are many other examples
of non-conformant implementations. A waste of time better spent
improving the clarity and correctness of a revised specification.
Also a real large potential downside for the computer industry and
a real windfall for lawyers.

Shame is the only realistic enforcement mechanism.

---

From: Etan Wexler <[email-masked]>
Date: Sat, 21 Oct 2006 13:40:55 -0400

David Morris wrote:

> the IETF.

I fail to grasp why this is so, but am not a lawyer. A claim of 
conformance to an Internet RFC is a form of advertisement. A false claim 
of conformance is a form of false advertisement. What difference does 
the strength or standing of the RFC bring to bear on the truth of the claim?

> The IETF is an effective way to cooperate an produce working 
> have minimal legal standing.

I neither suggested nor mentioned enforcing specifications in the 
absence of a claim of conformance, though one might construe my choice 
of subject line, “Enforcement of specifications”, as a mention of such 
enforcement.

> to have a feature required by the standard should be punished [...] 
> for false advertising when there are many other examples of 
> non-conformant implementations.

It would be reasonable that a court survey only misimplementations whose 
vendors make conformance claims. Of course, courts of law are not bound 
by reason. In any event, how many claims of conformance to RFCs are in 
circulation?

> [It would be a] waste of time better spent 

I agree, especially in the sense that a court case would be a terrific 
waste of my time. Even if winning court cases over false advertising 
were fast and inexpensive, I suspect that the overall effect would not 
be to increase conformance, but to reduce claims of conformance.

> Shame is the only realistic enforcement mechanism.

I agree. However, the set of enforcement mechanisms is a superset of the 
set of realistic enforcement mechanisms.

---

From: Ingo Struck <[email-masked]>
Date: Sat, 21 Oct 2006 19:17:28 +0000

Robert, Henrik,

> That is one reason. The ad-hoc stuff can be more secure than the
I Never encountered any ad-hoc stuff that was better than Basic, though.
Not to speak of digest. Especially nonces and mutual auth cannot
reasonably be done using cookies or any solution "above" the protocol.

> for new schemes in Mozilla.
This is one real showstopper. There must be a mechanism
for the client to drop the "session". For the server there
is no problem to drop it -- just send a new challenge.

> <https://bugzilla.mozilla.org/show_bug.cgi?id=355319>
This could be a requirement of any auth-scheme too, but
fixing this "bug" is a good thing.

Kind regards

Ingo Struck

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 21 Oct 2006 01:23:15 +0200

> <https://bugzilla.mozilla.org/show_bug.cgi?id=271383>

To make webmasters happy you also need to be able to embed the
credentials input in the 401 status response similar to a forms based
login, skipping the annoying popup outside of their look and feel
control..

> <https://bugzilla.mozilla.org/show_bug.cgi?id=355319>

Fully agreed.

Regards
Henrik

---

From: David Morris <[email-masked]>
Date: Sun, 22 Oct 2006 06:35:57 -0700 (PDT)

It isn't a logout button but a logout capability which is needed. The only
way for an actual logout button to be presented is for there to be an
active GUI. The server needs to be able to flush the stored credentials
via response code, header, etc.

While this is all nice, as the architect of several complex web
applications, I don't find a need for improved support. Any
developer who isn't satisified with the simplistic nature of the
web browser dialog has the freedom to prompt for credentials using
an https: based web page. Serious applications need better underlying
facilities for session authention and management than provided by the
likes of .htaccess, etc. By the time you have worked out the
integration of user authentication owned by the application but
prompted for by the browser via www-authenticate, etc., you will
have long since completed implemenation of a form / database based
implemenation where logout is not an issue.

> login, skipping the annoying popup outside of their look and feel

Waste of time ... and mucking of implementation layers ... if the dialog
isn't suitable, the developer of the web application needs to build it
using web page support which already exists.

> > <https://bugzilla.mozilla.org/show_bug.cgi?id=355319>

Not at all .. it needs to be an HTTP response code or header. Lets
keep the layers clear.

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 22 Oct 2006 17:53:12 +0200

sön 2006-10-22 klockan 06:35 -0700 skrev David Morris:

> an https: based web page.

What this discussion aims at is allowing the developer the exact same
freedom, but without throwing out the HTTP authentication support. In a
properly layered system authentication is a task of the web server, not
application. The application should only need to deal with
authorization.

Due to the lack of freedom and certain functionality currently
application designers are forced to venture into authentication.

>  Serious applications need better underlying
> likes of .htaccess, etc.

.htaccess is one of many ways a web server can be configured for
authentication. The thing here is that HTTP has a very powerful
authentication subsystem, but is today frequently ignored with each
application designer inventing their own plain-text (plus transport
encryption if lucky) scheme based on cookies to keep track of the user.

forms based authentication is all fine in the cases where authentication
is and must be all owned by the application, especially so if the
application acts as a proxy to other backend services.

but it's often not the case it you take a second breath and look at the
problem again. More often the application is doing authentication just
because it has to to meet the demands of designers (and users), and
would in fact benefit from being able to integrate cleanly with existing
authentication frameworks, and the web server is the natural place for
such integration. It's also the natural place for extending the
framework with new authentication schemes providing stronger protection
of users passwords and abilities to single-sign-on etc (very important
in intranet applications).

Regards
Henrik