Hi Sam.
> I'm confused by your comments on 3.1. I agree with you that an
> attacker could take for example a login password in today's systems
> and use that to to gain the information necessary to spoof other UI.
>
> The primary goal of this document is to propose requirements that make
> it difficult for the attacker to capture such a password.
Alright, I see that the intent of section 3.1 is actually to describe
capabilities that an attacker will *always* have, i.e., even in case it
does not know (and cannot acquire) a username/password from a victim
user. Maybe you can clarify this by changing the latter part of paragraph
2 of section 3.1 like this:
OLD
However the
attacker probably could not replicate the account summary page until
the attacker learned the user name and password because the attacker
would not know what accounts to list or approximate balances that
will look convincing to a user. Of course attackers may know some
personal information about a user. Websites that want to rely on
attackers not knowing certain information need to maintain the
privacy of that information.
NEW
However the
attacker probably could not replicate the account summary page
until the attacker learned the user name and password because the
attacker would not know what accounts to list or approximate
balances that will look convincing to a user. Preventing the
attacker from acquiring a victim's user name and password would thus
make it impossible for an attacker to spoof a user interface that
shows such individual data.
What I did is replacing the last two existing sentences with a new
one. Would you agree?
> Also in 3.1 you talk about on-path attacks. I guess this needs better
> wording because basically everyone who has read the document has
> commented on that phrase. So, examples of an on-path attack include
> mounting a MITM against TLS and hoping the user will click "accept
> this certificate" for the bogus cert you provide; DNS attacks; etc.
> I'm trying to say that attackers have these capabilities and that we
> need to evaluate both current and future systems against such attacks.
> How can I help clarify what I'm trying to say?
Here is some text that you could take to replace the currently last
sentence in paragraph 1 of section 3.1. If you wish, feel free to
copy and paste:
Mechanisms attackers use to accomplish this include links with a
misleading name or URI, which they may distribute in emails;
attacks against DNS; and man-in-the-middle attacks against a TLS
handshake. The former two attacks allow the attacker to pass
authentication because the victim user can be tricked into
accepting the attacker's certificate. The latter attack will
typically create a warning on the victim user's side, but many
users cannot make informed decisions on how to respond to such a
warning, making them inclined to accept the bogus certificate.
Hope this helps,
- Christian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf