Re: Straw-man charter for http-bis

[Henrik Nordstrom <[e-mail]>]

ons 2007-06-06 klockan 15:42 -0700 skrev Chris Newman:

> 2. HTTP Security
> 
> Phishing demonstrates that HTTP's present security mechanisms are not adequate 
> to meet some important requirements of the present users of the protocol.  I 
> would be uncomfortable moving HTTP from Draft Standard to Standard given this 
> situation.  It's likely that new work on HTTP security mechanisms (as outlined 
> by draft-hartman-webauth-phishing) is necessary.

Just a reflection on the phishing problem.

IMHO this is more of an UA and education problem, not so much a protocol
problem even if having something more secure than Digest would be a good
thing. But you should also be aware that making HTTP authentication
stronger won't make any of the common forms of phishing much harder.

The most common form of phishing is for collecting non-HTTP details
about the user such as credit card details or bank accounts, or for
phishing of the users login details to some financial service (bank or
similar), but such services tend to stop using static passwords once
hit..

There is imho three primary reasons why Digest has not gained much
foothold, neither being security.

a) Implementation rather complex, with few if any implementation getting
it entirely right..

b) It's inability to integrate well with existing authentication
frameworks on the server side.

c) UA integration, or web site owners requiring control over the login
process beyond a standard "login+password" dialog.

Then there is also the single-sign-on issue, but thats more of an
implementation thing than protocol. Digest fits just as fine in
single-sign-on models as the NTLM or Negotiate schemes widely deployed
for the purpose today, but due to it being a different authentication
mechanism than used for the desktop it's not used in that context.


Even if HTTP had the strongest authentication possible, fulfilling the
goals of draft-hartman-webauth-phishing etc, phishing would still be
equally possible by the exact same means used today. Or as long as the
primary key to the authentication process is a some piece of static
information provided by the user.

The phishing attacks is a soscial enginering attack on the weakness of
any static shared secret authentication mechanism. Works for login
+password, works for credit card details, works for bank account
details, works for very many forms of identity theft based on the user
providing any form of static secret.

Also in coming up with a usable secure authentication scheme to replace
Digest it's important to not underestimate the integration into existing
systems.

Equally important is the complexity of implementation. Very few if any
(certainly none of the commonly used browsers) implement Digest
correctly even if the ambiguous or weak parts of the specification is
taken aside.


Also it's worth noting that TLS + Digest already fulfills most of the
requirements of draft-hartman-webauth-phishing. There is some like the
enrollment criteria it do not address however.


> However, even with the 
> present security situation, I have no doubt that RFC 2616 is widely useful and 
> improving the technical clarity of the base specification is good work that 
> would benefit the Internet community.

It certainly is. RFC2616 provides the message protocol basics and
anonymous access to content, with hooks to hook in pretty much any
message authentication scheme.

> The minimum work necessary to make a 
> draft standard revision of the base specification complete would be to clearly 
> document the limitations of the presently deployed HTTP security mechanisms and 
> the fact they are not adequate for all situations.  Beyond that I consider it 
> inappropriate to hold publication of a useful revision hostage to new security 
> engineering work.

Good.

> 3. One vs. Two WGs
> 
> I would support the formation of two separate WGs: HTTP and HTTP security as 
> the people who have appropriate expertise for those efforts are not identical.

The people revising RFC2616 and 2617 to clarify the specifications and
prune out ambiguities or other specification errors could well be the
same group, but the group coming up with a secure message authentication
scheme beyond digest needs a quite different group of people and is not
really HTTP related. Such scheme is needed all over the computing
industry, covering pretty much all protocols not just HTTP. The problems
in coming up with such scheme is by no means HTTP specific.

> Indeed I'd be uncomfortable with a single WG that was both revising 2616 and 
> designing new HTTP security mechanisms as the latter may be helped by the 
> attention of security experts that likely have no interest in the former.

Exactly.

> From discussions here, I suspect it's unlikely an alternate specification would 
> be adopted by the WG in this case, especially because it might drop the target 
> status from draft to proposed for the reasons Keith mentioned.  However, this 
> is an important mechanism the keep the process open.

I would probably not be very comfortable with an largely rewritten
alternate specification within the target of specifying HTTP/1.1. If the
goal was to make a revision of HTTP and not a revision of RFC2616 then
yes, or even a requirement for such work. But I do not rule it out
entirely as there is many things about the structure of RFC2616 which
could be done better to not confuse new readers so much..

Regards
Henrik