Re: draft-hartman-webauth-phishing-03.txt

[Eliot Lear <lear at ofcourseimright.com>]

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 mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf