>>>>> "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.
>> I disagree that the references need to be significantly
>> expanded. I am familiar with the work you cited in your
>> message.
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. Obviously I will take direction from the
proto shepherd or responsible AD if they believe I should be adopting
different goals for when sources need to be cited.
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.
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.
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.
>> 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.
Eric> To be blunt, this is your job, not mine. We're talking about
Eric> major rewriting, not a couple of paragraphs.
We disagree about what the document should be trying to do.
If there were someone interested in doing the work necessary to make
the document cover the additional issues you'd like to see it cover, I
think it would be a good idea to at least consider whether that is
worth the delay. Absent such a volunteer, I think the main question
before us is whether that work is necessary or whether we have a
consensus that the current scope is OK.
>> It seems you have read the document and think I favor ZKPP
>> protocols.
Eric> No, I think discussing only ZKPPs and not non-ZK
Eric> challenge-response protocols gives an incorrect impression
Eric> of the state of play, as does failing to discuss PwdHash
Eric> style protocols. In the former case, because it neglects an
Eric> important alternative. In the latter case, it actually
Eric> excludes it due to the requirement for mutual auth in S 4.4
Eric> (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.
Eric> Wait, your claim is that we should discuss options which are
Eric> quite possibly not viable due to IPR considerations and
Eric> which in two cases WGs have declined to standardize, but
Eric> that it's not important to discuss several proposed and in
Eric> fact likely alternatives? I'm finding this a bit puzzling.
Yes. I think in a document like this it is more important to discuss
options that might appear promising but are in fact not than to
discuss options that are likely directions. However I don't feel
particularly strongly about this. If you think that the text about
ZKPPs would cause the reader to believe look in that direction I'd be
happy to work on it.
>> 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've tried not to expose my thoughts about how this should be solved
in the document.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf