Edit comment LC-2095 for Web Security Context Working Group

Quick access to LC-2056 LC-2057 LC-2058 LC-2059 LC-2087 LC-2088 LC-2092 LC-2093 LC-2094 LC-2095 LC-2129

Comment LC-2095

Comment Shortname:

Commenter: Francois Daoust <fd@w3.org>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeWeb Security Context: User Interface Guidelines... Web Security Context: User Interface Guidelines W3C Working Draft 24 July 2008 Abstract Status of this Document Table of Contents 1 Overview 2 Acknowledgments 3 Conformance 3.1 Product classes 3.2 Language conventions 3.3 Conformance levels 3.4 Conformance claims 4 Interaction and content model 4.1 Overview 4.2 Terms and definitions 4.2.1 Common User Interface elements 5 Applying TLS to the Web 5.1 Certificate Handling and Information 5.1.1 Interactively accepting trust anchors or certificates 5.1.2 Augmented Assurance Certificates 5.1.3 Validated Certificates 5.1.4 Logotype Certificates 5.1.5 Self-signed Certificates and Untrusted Root Certificates 5.1.6 Petnames 5.2 Types of TLS 5.3 Mixed Content 5.4 Error conditions 5.4.1 TLS errors 5.4.2 Error Conditions based on Third Party or Heuristic Information 5.4.3 Redirection chains 5.4.4 Insecure form submission 6 Indicators and Interactions 6.1 Identity and Trust Anchor Signalling 6.1.1 Identity Signal 6.1.2 Identity Signal Content 6.2 Additional Security Context Information 6.3 TLS indicator 6.4 Error handling and signalling 6.4.1 Common Error Interaction Requirements 6.4.2 Notifications and Status Indicators 6.4.3 Warning/Caution Messages 6.4.4 Danger Messages 6.5 Chrome Reconfiguration 7 Robustness 7.1 Chrome and User Interface Practices 7.1.1 Use Shared Secrets to Establish a Trusted Path 7.1.2 Keep Security Chrome Visible 7.2 Do not mix content and security indicators 7.3 Managing User Attention 7.4 APIs Exposed To Web Content 7.4.1 Obscuring or disabling Security User Interfaces 7.4.2 Software Installation 7.4.3 Bookmarking APIs 7.4.4 Pop-up Window APIs 8 Security Considerations 8.1 Active attacks during initial TLS interactions 8.2 Certificate Status Checking Failures 8.3 Certificates assure identity, not security 8.4 Binding "human readable" names to domain names 8.5 Warning Fatigue 8.6 Mixing Augmented Assurance and Validated Certificates 9 References
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

Hi,

I stumbled upon several obscure terms and sentences while reading the
spec (see list below). The terms are not defined. As far as I can tell,
they are all basic terms when one is used to dealing with security on
the Web.

Even though it contains "Security", the title looks friendly, and
doesn't seem to infer that a technical background on security is
required. Since there is no audience section, I expect I'm reasonably
well-versed into Web matters to understand the spec. That is not the
case: I understand the clauses, which is good, but I sometimes fail to
understand the rationale behind them.

Depending on the audience you are targeting, you may not want to define
these terms in the spec. That is the gist of this comment: the audience
is not defined. If your primary target is security experts, no need to
read the following list. If your primary target is user interface
developers, you should clarify them. In any case, you should probably
mention it and precise the expected knowledge before reading the spec so
that readers know what to expect beforehand.

Here is the list of security-related topics that are not so common for
other communities (well, "for me" at least, that is ;)):
- Section 5: The "TLS" acronym is actually never defined (only mentioned
in the references part).
- Section 5.1.5: "use of TLS provides confidentiality protection
services against passive attackers". What is a "passive attacker"?
- Section 5.1.5: "this can be strong evidence that protection against an
active attacker has been achieved as well". What is an "active attacker"?
- Section 5.1.5: "evidence that a man in the middle attack occurs". For
once, I know what a "man in the middle attack" refers to, but I'm not
sure everyone does.
- Section 5.2: "for both confidentiality and integrity protection". I
get the difference but that may be worth a little explanation as well.
- Section 7.1.1: same thing with "phishing" and "spoofing" although
probably known by more people.
- Section 8.2: "OCSP" stands for?

As a side note, I am totally fine with the relative complexity created
by the multiple definitions the spec already contains. Precision is good!

Thanks,

Francois Daoust,
W3C Staff Contact,
Mobile Web Best Practices Working Group.

Related issues: (space separated ids)

WG Notes: Discussed in: http://www.w3.org/2008/10/08-wsc-minutes.html Say thankyou but will not deal with details of protocols http://www.w3.org/2006/WSC/track/actions/526

Resolution: Thank you. We've added a reference to OCSP. The TLSv11 reference defines TLS in this context. We will not be putting additional details of those protocols in our spec. We hope the reader will either be familiar with them, or follow up with the references or generic web searches of the concepts.

(Please make sure the resolution is adapted for public consumption)