ietf
[Top] [All Lists]

Re: Review of draft-hartman-webauth-phishing-05

2007-08-22 06:12:26
Part of the problem may be historical: Requirement documents are a relatively recent phenomena and likely postdate 2026. I suspect the original intent of informational documents was to document non-IETF protocols for the benefit of implementors, as well as record various other non-standards items such as April 1 poetry or workshop results, where it is pretty clear that this is the opinion of the author or some definable group, such as the IAB.

On the other hand, I have yet to see working group-issued requirements documents being used for anything except shadow boxing (and, occasionally, recording some early WG thinking), so maybe we shouldn't take them too seriously.

Rather than an IESG note or in addition to, I think the author should clearly state, in the abstract, that this is a personal opinion only.

Henning

On Aug 22, 2007, at 7:47 AM, Sam Hartman wrote:

Ah.  I must admit that I find the whole concept of informational
documents a heck of a lot less useful, but your reading of 2026 is of
course correct.  I'll probably still end up treating informational
documents as close to ietf consensus statements (but not
recommendations) in my head because honestly I cannot find any other
way to think about it that makes any sense to me.  I certainly view an
informational docmuent that has gone through an ietf last call as a
statement from the IETF.  We'll add this to one of the many areas
where I completely fail to get RFC 2026.


I definitely don't want to block other work with this document.  I
think that to be particularly useful I'd like to get to a point where
we can say that having authentication schemes that meet these
requirements would be useful and that for some value of we
significantly greater than me, we think that would be a useful step
along the road to combatting phishing.  I thought I was trying to have
that discussion here; you at least seem to think that is not the case.
At some future point we might charter work with the goal of doing
something similar to those requirements; in such a case, we might
decide to hold that work to these requirements.  We're not discussing
doing that today.

If I believe there is a reasonable chance of success I'm willing to
put in significant effort towards achieving my goal.  Absent that
belief I'm more interested in getting something out and working on
running code.


So, Here is a proposed IESG note that I think is consistent with my
intent and RFC 2026:

This document proposes requirements for HTTP authentication that are
intended to help combat the problem of phishing.  These requirements
attempt to reduce the consequences of a user being tricked into using
a server provided by an attacker instead of the server they intended
to trust.  These requirements have no normative force; publication of
these requirements does not bind future work to follow them.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf