>>>>> "Eliot" == Eliot Lear <lear@xxxxxxxxxxxxxxxxxxx> writes:
Eliot> Sam, I've reviewed draft-hartman-webauth-phishing-03.txt.
Eliot> In general I agree with the tone of it in terms of how to
Eliot> address these sorts of threats. However, I have a problem
Eliot> with its scope. The problem you discuss extends well
Eliot> beyond just HTTP already.
I don't understand what you mean here. If you mean that other
protocols besides http are vulnerable to phishing, I agree. However I
do not believe it is desirable to generalize this document to the
point where it talks about other protocols. Doing so would make this
document harder to understand for those thinking about the web and
would make an already incredibly complicated problem harder.
Eliot> Furthermore, your assumption
Eliot> that the computer is secure is a bad one.
I think that some version of this assumption is necessary. Ultimately
without some trusted computing base, you cannot trust your security.
I don't think it is appropriate for the IETF to bite off the problem
of browser design or host security. I do agree with you (and the
document does say) host security needs to be considered as part of
security analysis .
Now, your trusted computing base can be a lot better designed than
today's browsers. You may have secure OS components, possibly even
assisted by hardware, thta are part of the security solution. But
somewhere, whether it is on a smart card, in some trusted hardware, or
in software that is somehow validated, you do actually need software
that you can trust.
Even one-time passwords have problems absent trusted software. In
particular, you cannot tell whether you are giving the one time
password to the right entity.
Perhaps the requirement is unclear. I certainly don't mean that
browser designs and their security architecture needs to stay the
same. But ultimately your trust needs to be based in some software
somewhere.
Eliot> I'm not saying
Eliot> that we should require smart cards,
Note that requiring smart cards doesn't speak to this assumption one
way or another. First, traditional smart cards are not enough that if
the smart card is trusted and the rest of the system is not, you can
get security against phishing. Once you've given your pin to the
system, you have no idea what all it goes and uses your smart card to
do.
And to the extent that smart card would help, they are secure. If you
allow the attacker to run software on your smart card, it destroys
your security just as thoroughly as in a non-smart-card system where
you let the attacker write browser extensions.
Eliot> as a matter of threat analysis, you should allow for the
Eliot> idea that the computer may not be secure, and hence allow
Eliot> for approaches that address that problem.
Perhaps it would help the discussion if you would describe such a
solution. I think it might make it more clear what your real concern
with this requirement is.
Eliot> However, you need to consider your other requirements in
Eliot> the context of such approaches.
Again, I think examples would be useful here.
Eliot> I also think Section 4.1 is unnecessary. Attempting to
Eliot> simply repair passwords is one legitimate approach, but it
Eliot> shouldn't be the only one. In fact, I would argue that you
Eliot> are setting up users for very serious problems by
Eliot> perpetuating an approach that requires them to either write
Eliot> down their passwords or use the same one for multiple
Eliot> sites. This section, IMHO represents a requirement for
Eliot> poor modularity.
I completely agree that approaches other than passwords should be
supported. Section 4.1 says this today. However I do believe that
support for things that have the same usability profile as passwords
is an absolute requirement. In particular, I believe people need to
go to a computer they have never used before and authenticate only
with the information stored in their head.
I'd rather follow this work up outside
the IETF than lose this requirement.
Eliot> Also, you have a number of editorial oddities. A "Google
Eliot> paper" should be treated as any other reference, for
Eliot> instance.
Help with these is appreciated.
Eliot> Finally, quite a number of your requirements are
Eliot> unclear.
Help adding clarity is always appreciated.
Eliot> See for instance your first sentence in 4.1. The
Eliot> second phrase is mystifying.
I'll admit that it seems clear to me so your help in understanding the lack of clarity is greatly appreciated.
Eliot> I would appreciate the opportunity to work with you on the
Eliot> above issues, as well as improve your introduction, which I
Eliot> believe warrants some additional effort (I am tempted to
Eliot> ask that you include a glossary),
I'm happy to work in the spirit of our rough consensus process with
anyone who wants to contribute.
--Sam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf