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

From: Sam Hartman <[email-masked]>
Date: Fri, 25 May 2007 13:16:11 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> 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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eliot Lear <[email-masked]>
Date: Sat, 26 May 2007 13:58:00 +0200

Hi Sam,

> 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.

> security analysis.

I agree with what you say here, and would suggest that you clarify your 
text accordingly.

> password to the right entity.

And include this too.
> same.  But ultimately your trust needs to be based in some software

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.

> system, you have no idea what all it goes and uses your smart card to

I agree.

> 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".
> with this requirement is.

Ok, does the above explain this better?

> 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.

> 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 crypFrom [email-masked] Mon May 28 21:09:33 2007
Date: Sat, 26 May 2007 13:58:00 +0200
From: Eliot Lear <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: 'IESG' <[email-masked]>, IETF Discussion <[email-masked]>
Subject: Re: draft-hartman-webauth-phishing-03.txt

Hi Sam,

> 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.

> document does satographic 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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 May 2007 09:54:37 +0200

Sam,

I've reviewed draft-hartman-webauth-phishing-03.txt.  In general I agree 
with the tone of it in terms of how to address these sorts of threats.  
However, I have a problem with its scope.  The problem you discuss 
extends well beyond just HTTP already.  Furthermore, your assumption 
that the computer is secure is a bad one.  I'm not saying that we should 
require smart cards, as a matter of threat analysis, you should allow 
for the idea that the computer may not be secure, and hence allow for 
approaches that address that problem.  Note I did not say "require".  
However, you need to consider your other requirements in the context of 
such approaches.

I also think Section 4.1 is unnecessary.  Attempting to simply repair 
passwords is one legitimate approach, but it shouldn't be the only one.  
In fact, I would argue that you are setting up users for very serious 
problems by perpetuating an approach that requires them to either write 
down their passwords or use the same one for multiple sites.  This 
section, IMHO represents a requirement for poor modularity.

Also, you have a number of editorial oddities.  A "Google paper" should 
be treated as any other reference, for instance.  Finally, quite a 
number of your requirements are unclear.  See for instance your first 
sentence in 4.1.  The second phrase is mystifying.

I would appreciate the opportunity to work wy) host security needs to be considered as part of

And include this too.

I agree.

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 crypith you on the above issues, 
as well as improve your introduction, which I believe warrants some 
additional effort (I am tempted to ask that you include a glossary), but 
I do not support this document moving forward at this time, although I 
do support it moving forward once these issues are addressed.

Thanks,

Eliot

tographic algorithm flexibility.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 May 2007 09:35:10 -0400

I'm at an interop event this week, but I think I now get your concern
with host security and section 4.1 and would like to propose fixes.

Thanks for working with me to understand the concern.

--Sam