W3C home > Mailing lists > Public > public-wsc-wg@w3.org > December 2007

wsc-xit review comments

From: Johnathan Nightingale <johnath@mozilla.com>
Date: Mon, 3 Dec 2007 22:59:49 -0500
Message-Id: <CF0B4E76-A858-4A49-8D44-AC193339D3EF@mozilla.com>
To: W3C WSC W3C WSC Public <public-wsc-wg@w3.org>

Hey Folks,

My FPWD review comments below.  I hope to translate these into actions/ 
issues soon, but I figured that since I had notes, I might as well  
send them out before Mail.app decides to eat them, or something.  If  
Mez or Thomas wants to give me an action to transcribe them into  
issues, I'll gladly take it, otherwise I'll aim to get to them this  

I'll also blog about the FPWD somewhere that is syndicated by the  
Mozilla community, to solicit any feedback the community wants to offer.



Review notes by section:

4.2.2 - s/or by exploiting/by exploiting/

5.2 - I'm not sure why we think this is appropriate work for us to  
do, versus leaving to groups more directly focused on cryptography.   
At very least, it doesn't seem normative, and doesn't contain  
obviously prescriptive text.

5.3.1 - We are supplying normative language for no-interaction certs  
which, aiui, are still purely conceptual.  That feels like defining  
new protocols to me, particularly since the definition cites a non- 
existent reference at the moment.  If this is out there in the world  
and deployed, then I think our language is fine, but I don't think we  
want to be in the business of defining x509 extensions.

5.5.2 - Should we make an explicit exception for the paypal case  
here, where typing "paypal.com<enter>" into a location bar causes an  
immediate redirect to https://www.paypal.com?  Treating that as  
"insecure" feels wrong to me, even though as a matter of general  
principle, redirecting through http is indeed dangerous.

5.5.3 - As I understand it, this creates an inescapable obligation on  
user agents to store certificate history.  Aside from the challenge  
that no major browser currently does this (as far as I know), this  
creates privacy and implementation concerns around data retention.  We  
don't say how long this information must be kept, but we say the  
browser MUST treat it as a change of security level, which does not  
seem to leave open the possibility of not storing it.

6.3 - I continue to feel that this isn't a recommendation we should  
make.  It would be interesting fodder for browser extension  
developers, but even then, our shared bookmarks contain specific  
research around security scoring in primary UI and have found it to be  
non-helpful in preventing attack.  If the intent of this  
recommendation is not to prevent attack, then we should be clear about  
what the intent *is* because I don't think it provides helpful context  
on its own outside of attack resistance.

7 - This section should use the language seen elsewhere regarding  
examples, i.e.  "This section is normative.  Examples are  

7.1 - I'm still not sure why we need to specify a matching algorithm  
here.  If a given cert is valid for the site by the rules of TLS in  
general (and possibly our KCM provisions in particular,) then I think  
it ought to have access to the PII data regardless.  Inventing our own  
matching rules seems like the wrong approach, and lets us reinvent  
holes that other protocols have patched (e.g. by my reading, an  
attacker that obtained a DV cert from a CA that doesn't verify  
anything except domain control could pass rule 4 by specifying  
arbitrary content for the Subject field, assuming the legitimate site  
used the same CA.)  Even if none of us can think of plausible attacks,  
that's still no match for just falling back on matching protocols with  
longer lifetimes and broader deployment.

7.2 - I don't think the fact that it often happens to work is good  
justification for MUST language requiring user agents to tinker with  
the URL to swap from http to https.  At most, that seems like MAY, but  
I would honestly just remove it - the way to find the secure login  
page is to have the site direct the user there.  Swapping to HTTPS  
could quite plausibly, for instance, render the same insecure page  
which would then submit insecurely.  This appears to be Issue-123.

7.8 - It's not clear to me what the requirement is on the user agent  
with the text "remains forever the same."  One assumes that new  
installs don't need to preserve this, and also (for browsers that  
manage things in such ways) not new profiles - what about browser  
versions?  If the rest of the chrome is updated, does altering the UI  
here render UAs non-conformant?

7.9 - The last SHOULD line here assumes the existence of an alert  
service which we don't talk about elsewhere.  I think we should just  
drop it, and let the implementers of such a service anticipate the  
hook into formfiller, rather than the other way around.

Overall, my concern with 7 is that I think it will not see a lot of  
implementation, that browsers will not willingly turn off their form- 
fillers, which are generally a positive usability-wise, in favour of a  
more-secure but deliberately less helpful approach.  I don't mean that  
pejoratively, it's deliberate that, for instance, it won't "help" you  
supply your credit card number to an http form, but nevertheless I  
suspect it's not a trade-off browsers are likely to make, which could  
sink conformance rates.

8.1.1 - While I understand the motivation, I would be surprised if  
many user agents would perform the required user study strictly for  
the purposes of conformance.

8.1.2, 8.1.3 - I have sent recommendations for alternate text to the  
group as part of ACTION-346.

Johnathan Nightingale
Human Shield
Received on Tuesday, 4 December 2007 04:00:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:51 UTC