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