At Mon, 20 Aug 2007 13:12:51 -0400,
Sam Hartman wrote:
Hi, Eric, responding as an individual.
Obviously, I disagree with your basic claim that it is too early to
write a document like this.
Not quite. My claim is that the IETF should not be publishing
a document like this and then requiring that future work conform
to it. I don't have a problem to it being published as basically
a White Paper with a clear understanding that protocol proposals
will not be held to this standard. Hence my suggestion for
an IESG Note to formalize this understanding.
I disagree that the references need to be significantly expanded. I
am familiar with the work you cited in your message.
Yes, but the purpose of the references section isn't for you, but for
consumers of the document. A document which does is neither
an adequate guide to the state of the art (which this one is not)
nor contains pointers to the literature does not serve the community
well. More importantly, if you're going to impose *requirements*
on the community, they should be clearly informed by the existing
state of the art. The only way to do so is to actually discuss
that topic, not have the reader be forced to take on trust that
the literature supports the author's position.
To give one concrete example, there is an emerging body of work (with
the Shechter paper I cited being the best-known example) a variant of
one of the techniques you specifically recommend in S 4.2 (a shared
secret between the UI and the user, though in this case it was a
shared secret with the bank with a similar UI metaphor) was shown
to be of limited effectiveness.
To give another example: two of the other papers I cited (HWF05 and
RJBMM05) describe UI-only mechanisms that provide for unique
per-server passwords and a special UI with no modification whatsoever
to the network protocol. I appreciate that you feel that other
approaches are more promising, but the fact that this document
but that doesn't mean that a document of this type should pretend
that they don't exist.
If you would
like to propose specific text that improves the document and cites
those references I'd like to consider your specific text suggestions.
To be blunt, this is your job, not mine. We're talking about major
rewriting, not a couple of paragraphs.
It seems you have read the document and think I favor ZKPP protocols.
No, I think discussing only ZKPPs and not non-ZK challenge-response
protocols gives an incorrect impression of the state of play,
as does failing to discuss PwdHash style protocols. In the former
case, because it neglects an important alternative. In the latter
case, it actually excludes it due to the requirement for mutual
auth in S 4.4 (as well as not mentioning it.)
It's certainly true that in a world without patents I think they would
be interesting to explore. However I wanted to discuss them mostly
because I thought that the patent problem was important to turn out.
Wait, your claim is that we should discuss options which are quite
possibly not viable due to IPR considerations and which in two cases
WGs have declined to standardize, but that it's not important to
discuss several proposed and in fact likely alternatives? I'm finding
this a bit puzzling.
I think the primary concern will be what we can manage to get
deployed not protocol details.
I've tried not to expose that too much in the document; I understand
we disagree.
I have no idea what you're talking about here.
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf