At Tue, 21 Aug 2007 13:05:59 -0400,
Sam Hartman wrote:
"Eric" == Eric Rescorla <ekr(_at_)networkresonance(_dot_)com> writes:
Eric> At Mon, 20 Aug 2007 13:12:51 -0400,
Eric> 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.
Eric> Not quite. My claim is that the IETF should not be
Eric> publishing a document like this and then requiring that
Eric> future work conform to it. I don't have a problem to it
Eric> being published as basically a White Paper with a clear
Eric> understanding that protocol proposals will not be held to
Eric> this standard. Hence my suggestion for an IESG Note to
Eric> formalize this understanding.
I don't think it would be appropriate to publish this document as a
BCP that future HTTP authentication work needs to be held to. I do
hope that we have consensus these are good requirements, that it would
be desirable to work on solutions that meet these requirements and
that it would be a reasonable discussion to ask why particular work
did not plan to meet these requirements or whether these requirements
should be referenced in chartering work. I suspect you are not part
of such a consensus if it exists.
Again, I don't understand how you're claiming this document should be
used. Clearly, it would be reasonable for someone in the future to
argue that it was reasonable to work on solutions that met requirements
listed in arbitrary papers published in other venues, or to ask why
proposed work didn't meet those requirements. This is a reasonable
question to ask for any document, regardless of publication venue.
On the other hand it would be reasonable to say "yeah, I haven't
read that document, but feel free to reiterate its arguments if you
think they apply." Is it your belief that if the IETF publishes this
document as Informational that it should have some status other than
this?
Eric> Yes, but the purpose of the references section isn't for
Eric> you, but for consumers of the document. A document which
Eric> does is neither an adequate guide to the state of the art
Eric> (which this one is not) nor contains pointers to the
Eric> literature does not serve the community well.
I disagree that it is a goal of this document to serve as a guide to
the state of the art nor is it necessary or desirable to contain
pointers to the literature in this space. In general I've tried to
cite sufficient sources to make the requirements clear , not to
justify them. I believe this practice is consistent with a lot of
IETF requirements documents.
Yes, but in most cases, there is a historical record in the form
of the WG mailing list which justifies the requirements. That
situation does not apply here.
Eric> More
Eric> importantly, if you're going to impose *requirements* on the
Eric> community, they should be clearly informed by the existing
Eric> state of the art. The only way to do so is to actually
Eric> discuss that topic, not have the reader be forced to take on
Eric> trust that the literature supports the author's position.
I think we disagree in principle. However you mention a number of
cases where the document would be improved by specific citations. I
appreciate that feedback and will work on including citations.
Not to put too fine a point on it, but these are examples, not an
exhaustive list. This is a systemic issue and it's not fixed just
by fixing these specific cases.
Eric> To give one concrete example, there is an emerging body of
Eric> work (with the Shechter paper I cited being the best-known
Eric> example) a variant of one of the techniques you specifically
Eric> recommend in S 4.2 (a shared secret between the UI and the
Eric> user, though in this case it was a shared secret with the
Eric> bank with a similar UI metaphor) was shown to be of limited
Eric> effectiveness.
I will include discussion.
I don't see how discussion helps.
This draft basically recommends a technique which may well not work.
That's fine if you're writing a white paper, but I don't see how it
can go in a requirements document, especially as controlling where
the user types their password is the heart of the problem
Eric> To give another example: two of the other papers I cited
Eric> (HWF05 and RJBMM05) describe UI-only mechanisms that provide
Eric> for unique per-server passwords and a special UI with no
Eric> modification whatsoever to the network protocol. I
Eric> appreciate that you feel that other approaches are more
Eric> promising, but the fact that this document but that doesn't
Eric> mean that a document of this type should pretend that they
Eric> don't exist.
I'll take a look at where such a discussion could fit in and see if it
makes sense.
It's more than just including discussion. As I indicated below,
your document actually prohibits this type of solution.
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf