At Tue, 21 Aug 2007 13:05:59 -0400, Sam Hartman wrote: > > >>>>> "Eric" == Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf