[secdir] secdir review of draft-hartman-webauth-phishing-09.txt

["Carl Wallace" <[e-mail]>]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This abstract of this draft indicates it "proposes requirements for
protocols between web browsers and relying parties at websites".
Generally, the audience for the requirements seems to be broader than
the abstract states and at times it was difficult to figure out who the
intended audience is.  It may be worthwhile to separate the requirements
into UI requirements and protocol requirements.  

In paragraph 5 of section 1, the reference to "social engineering
attacks against TLS server authentication" is unprepared and is not
elaborated on.  This is also stated in the Security Considerations
section.  An example or two would help.  Are there any additional
requirements that would help reduce the effectiveness of these attacks?

In the first paragraph of section 3, there's a missing assumption that
user's trust anchor stores are sufficiently poorly maintained (or CA
issuance practices sufficiently broken) to enable the TLS certificate
presented by the attacker to be validated.  Section 4 should assert a
requirement somewhere to properly maintain a trust store and validate
certificates where used.  

In the third paragraph of section 4.4, the statement "a shared secret
will provide a better confidence" isn't necessarily true.  "will" should
be "may" or "will often".  

Section 4.7 should address how a user can gain confidence in the server
when setting up a new account.  It's also not clear what the aim is in
this section.  Is the enrollment referenced here with a web site where
an identity provider is used (and has a password for the user) or
something different? 

In section 5, the statement "validation of the certificates used in
TLS...can be useful" is an understatement.  This should be required.

Not sure if this draft is the right place to comment, but, if
requirements are for UI designers, it may be worth including a note
about credential selection dialogs displayed to clients engaged in
mutual authentication with public key credentials.  It's fairly common
for the selection dialog to be pruned such that no credentials are
displayed due to certification path complexities between the trust list
of the server and the user's cert.  It's also common for too many
credentials to be displayed (including those that will be invalid in the
given context).

In section 1 and in Security Considerations, users gain assurance that a
web page was "generated by a party that either knows their password or
who is authenticated by an identity provider who knows their password".
Why is this important?  Shouldn't the assurance be that the page was
generated by the entity authenticated as described in section 4.4?  How
does this reconcile with the requirement to not share a password during
enrollment?

The draft identifies password reuse as a problem but does not mention
usage of tools to facilitate management of different passwords (aside
from avoidance of plaintext password protocols).  This seems worth
discussing since the Security Considerations highlights a need to
maintain passwords for legacy systems plus passwords for systems that
meet these requirements or maybe it's just out of scope.


Nits
- In section 1.2, change "smoothe" to "amooth".
- In the last sentence of the second paragraph in Security
Considerations, change "there exposure" to "their exposure".
- Change "OTher" to "Other" in title of Section 4.1
- In section 4.1, change "do not have smart cards" to "do not have smart
card readers".
- The abstract asserts a MUST that is not repeated in the body of the
draft.  

_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir