Hi Sam,
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.
First, I think you invite multiple disparate solutions for different
protocols when you think this way. That's one of the reasons we're
here today, in fact. "Doctor, it hurts when I bang my head against the
wall..." Instead, I propose that you focus on HTTP as an example as to
how these authentication requirements should be applied, but also keep
in mind a disparate example like 802.11 networks. I honestly don't
think you're very far from this at all, as things stand.
Also I don't think the problem is really that hard. The fundamental
issue is that the other end is not authenticating itself end to end.
Why is that limited to HTTP? Answer: it's not. We need a modular
authentication architecture that is independent of the protocol. That
architecture needs to scale up AND down.
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.
I agree with what you say here, and would suggest that you clarify your
text accordingly.
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.
And include this too.
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.
Yes. I am applying what I'll loosely call a "Bellovinian" approach that
says that you need the appropriate level of modularity to solve
authentication. The reason it's important to address is that it MUST be
possible to implement the appropriate communication channel between
components in such a way that it is opaque between the ends.
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.
I agree.
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.
And so you need a system in which sensitive transactions are
communicated to the module with sufficient information that the user can
say, "Yes, this is what I intend" or "No, someone is yanking my chain".
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.
Ok, does the above explain this better?
Eliot> However, you need to consider your other requirements in
Eliot> the context of such approaches.
Again, I think examples would be useful here.
Section 4.5, the menu of means to meet the requirement is incomplete.
Consider the case I mentioned above.
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.
The other is also an absolute requirement. That's what I'm saying.
Require passwords all you want. Just also require a flexible enough
approach to address newer authentication techniques. View it, if you
will, as you would cryptographic algorithm flexibility.
As to the other issues, I'll approach you offline with suggested textual
changes to improve the clarity of the document. Many are editorial in
nature. As to those that are more than editorial, let's discuss and see
how far we get.
Eliot
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf