WSC-XIT review

Attached is my review of "Web Security Context: Experience, Indicators, and
Trust (Editor's Draft 28 November 2007)".

1. Overview- Paragraph 2
- remove (we hope) (we hope, again)
- The last phrase "making it easier to enter sensitive data into legitimate
web sites than to enter in illegitimate sites" seems odd to specify here.

4.1.  Paragraph 1 "Where requirements or techniques are specific to certain
modalities, these are made explicit, and are part of the preconditions for
applying the requirement or technique."  What does "certain modalities"
mean?

4.1 Overview. Paragraph 2 - remove "then this term is used on a conceptual
level:".

4.2.2. Terms and Definitions.
- I assume that the term "whack-a-mole" attack is one that we are inventing,
since I have never heard it before.
- Why is there only one attack defined?  Other attacks mentioned in this
document include impersonation attacks, man-in-the-middle attacks, etc.  We
have defined these elsewhere.

5.3.  Certificates
In general, I can't evaluate this sections, because I can not tell what
terms are self-defined and which are defined externally.  Which are based on
extensions that are pre-existing?

5.3.1 This section is confusing- some examples of where more precision and
clarity would help:

 "Definition: An Augmented Assurance Certificate is an identity certificate
that asserts that the subject entity has been authenticated by means of a
process that has been audited and is designed to establish accountability in
accordance with an industry standard set of criteria, e.g. [EVSSLCERT]."
- what exactly does "subject entity" mean?
- do industry standards include standards body standards (e.g. IETF)?

"This specification assumes that Web user agents establish that a trust root
is [Definition: AA-qualified  ] through security-critical
application-specific out-of-band mechanism. It is further assumed that
Issuer and Subject information included in Augmented Assurance Certificates
is valid, and intended to be displayed to users."
- does "intended to be displayed to users", mean that users should be able
to view it or understand it?

"Implementations MUST NOT enable users to designate trust roots as
AA-qualified as part of a different interaction. Implementations MAY make
user interfaces available for the purpose of designating AA-qualified trust
roots. Such user interfaces MUST be focused on this specific task. In
particular, the notions of an AA-qualified trust root and an interactively
accepted trust root are mutually exclusive."
- "as part of a different interaction" - specify the specific interaction
you are referring to
- "this specific task" - specify the task

5.3.4 - Are no-interaction certificates defined elsewhere?  The link to
reference [ref-UESOID] is broken.  In the "NoSecurityIndicator" proposal,
the reference link to PKIX discussions broken.

5.3.6 - As defined, with "interactive certs", the user is performing a task
unrelated to certs, and in "non-interaction certs", the user's primary task
is to add a CA cert to the browser's root store.  The terminology is
confusing.  More importantly, I don't understand this distinction, because
adding a CA cert will never be a user's primary task, unless they are a
system administrator.  If a user receives instructions from their system
administrator to add a certificate, their primary task is always to access
some system resources, not to install the cert.  Similarly, if an attacker
instructs the user to accept or install a certificate through social
engineering, the user's primary task is whatever urgent task the attacker
has conjured up for the user.

5.5. Change in Security Level
This section does not discuss how changes in security level will be
communicated to the user.
5.5.3.  We should acknowledge that we are decreasing the incentive of sites
to make cert changes (e.g., moving to EV).
There is a tension between privacy and security here, that should be
acknowledged if not addressed.  If we recommend that browsers retain  a
historical record of sites visited and their previous security level, we
might specify how users can protect this information (e.g., from other users
on a shared machine), prevent it from being recorded (e.g., anonymous
browsing mode), or delete it (if users can delete their cache, just as they
can delete cookies today, this introduces new attacks).

6.1.  Identity Signal
"No claim is made about the effectiveness of these signals to counter
impersonation attacks."  If this proposal is not effective in helping users
to detect impostors, it is hard to claim that it aides users in determining
the legitimate identity of a website.  Surely, there must be some benefit
claimed here, so we should state it.  The intended outcome should be
specified for all recommendations, otherwise we have no way to evaluate
effectiveness.

Attackers will copy the indicator that is used for the "legitimate, verified
identity" and place it into the content of websites, just as attackers copy
locks and Verisign seals today.

6.1.2.  "Information displayed in the identity signal MUST be derived from
attested certificates, from user agent state, or be otherwise authenticated.
Web user agents MUST NOT use information as part of the [[identity signal]]
that is taken from unauthenticated or untrusted sources."
What does "user agent state" here mean?

6.2.   Page Security Score
The difference between this proposal and the Identity Signal is that Page
Security Score is intended to convey the security rank (relative to other
websites), while Identity Signal is intended to convey information about
identity and not about security.  The lock icon today conveys two states
(SSL or non-SSL usually indicated by the lack of a lock icon).  I believe
that the Identity Signal conveys two states (identity verified, or identity
unknown) with supplementary information about the website's and the
verifier's identities.  If Page Security Score envisions some other type of
visualization (e.g. with more states or gradations), this should be stated.

We should have at least one instance of a proposal that is shown to be
effective before making a recommendation on it.

As with the Identity Signal proposal, attackers will copy whatever
representation is used for the "high security score" and place it into the
content of websites, and a large fraction of users will be fooled.

6.4  Error Handling
6.4.2.  "... if it is possible to construct a request URL from certificate
information, then Web user agents MAY offer users the additional possibility
to follow this URL".  What is "a request URL from certificate information"?
Being more specific would help.

7.  Safe Web Form Editor
In general my concern for the other proposals is security (ease of spoofing
and other impersonation attacks).  My concern with this proposal is instead
with usability.  This proposal suggests dramatically new gestures and
interfaces, and will take a sufficient amount of implementation and
usability testing to make it intuitive and easy to use.

9. Authoring and Deployment Best Practices
9.1 "Do not put Security Indicator images to indicate trust in content. This
specification requires that web pages MUST NOT include trust indicating
images such as padlocks in the web content."  This statement is too broad,
because it includes websites that include secret images (or other shared
secrets chosen by the user) to create a trusted path between the user and
the website.

We can ask legitimate websites not place indicators in the content of
webpages, but attackers will continue to use them.  Web designers (and
attackers) understand that the user's locus of attention is in the content,
and a well placed indicator can enhance credibility and sales.  The real
problem, IMO, is indicators that can be easily copied, not where they are
placed.

11 Security Considerations.
This is an important section, but why is it here?  It seems that these are
general security considerations that might apply to more than one proposal.
This list is not comprehensive.  That is, all of the proposals have some
security or privacy considerations (such as spoofing, secure storage
requirements or shifting the attacks from one type to another) that should
be listed here or in their respective sections.  (Note that I think this
section should be expanded, and perhaps moved, but not deleted).

11.1 This is an important section, but I don't understand the
countermeasures, and they seem added as an afterthought.  Some people might
wonder why the countermeasures are not included in our recommendations.
("Countermeasures against this threat include the prior designation of
high-value sites, for which extended validation or attested certificates are
required (causing a change of security level during the attack scenario
described above), and communication of certification and TLS expectations by
a mechanism separate from HTTP, e.g. through authenticated DNS records.")