Re: ACTION-209: What is a secure page?

"Some clients give a warning (which can be disabled) when the displayed 
document changes from an unsecure to a secure mode, or vice versa, "

It seems patently obvious to me that a "warning" is the last thing you 
want when things are getting more secure. I can't figure out how this 
convention ever got started (except I can, it was the easy thing to do 
quickly with little thought). 

"Never use an image of a padlock (or similar "this is secure" indicators), 
at least in a context where the user will assume it means "this page is 
safe". A possible valid use is beside a "Sign on" link/button that will 
take the user directly to the secure server without redirects. "

Emulating user agent security context indicators (SCIs) can be considered 
a form of spoofing. Our recommendations will include some SCIs that can't 
be spoofed. I'm willing to believe that our recommendations will also 
address SCIs that are somewhat spoofable; visible or other representations 
that are predictable and so can be reproduced to some extent in page 
content. I also believe that we should recommend as good practice to web 
site/app developers that they not spoof/emulate SCIs that user agents use. 
I believe that giving any exceptions to this is bad practice; it's hard 
enough on the user's as it is. So I disagree witht he possible valid use. 
If there's a need for sign on links/buttons to indicate their SCI, we 
should be coming up with recommendations on user agents to do that. 
Perhaps you can extend your proposal with that. 

It seems like there's also some Good Practice recommendation there about 
redirects, but I can't quite tell what it is. 

"All login forms to a secure service must be served from a secure server, 
and must not not be included inside a page containing unsecure content. "

For understandability and conformance, you'll need to use differenct words 
for "secure" and "unsecure", and/or define those words. The definitions 
you would propose may be implicit in your lead in material; call them out 
explicitly. I need them for several other proposals you make. 

"If a service require secure login,"

I'm not a fan of insecure logins. You seem to be allowing their existance. 
I think that's a bad idea. 

"then all transactions/presentations based on those credentials must be 
protected by the same level of security. "

You need to define levels of security. I need that for some of your other 
proposals as well. 
I'm concerned that that might be out of our scope, but not certain. I 
could see some Good Practice recommendations around how difficult it is 
for users to understand/track varying levels of security and the 
importance of consistency within some scope/context. 

"Cookies on unsecure connections are vulnerable to interception, and can 
be used for replay attacks even if they were set by a secure server, and 
servers should not set credential cookies from secure servers that can be 
sent unencrypted. "

I personally wholeheartedly agree, but am almost sure this is out of 
scope. I encourage you to put anything that seems to be out of scope in 
http://www.w3.org/2006/WSC/wiki/FuturesAndOnePluses

"Change from and unsecure to secure parts of a service should be done by 
direct links, and not redirects. If unsecure->secure redirects are needed 
then the redirect should be immediate, and not multistep. "
I can't quite tell how this is in scope. How does it relate to SCIs and 
helping users with trust decisions?

"Do not POST passwords from an unsecure page (even if the form is in a 
"secure" frame) to a secure server."
This does seem out of scope. In fact, it seems like the TAG password 
finding that has stalled:
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html

Raman and I discussed that finding at the last AC meeting, and we'd both 
like to get it going again. If you (or anyone) wants to put energy into 
it, let me know. I'm so far behind on detailed review of all the good work 
people have been doing, it's not coming up on my list anytime soon. 

"Should not display a padlock if (at least) one of the resources required 
user interaction to accept the certificate of the server "
I disagree that self signed certificates are inherently less secure than 
CA generated ones. My enterprise runs on them. I do continually find it 
frustrating that there's not some administrative way to push down 
certificates, so that this use case can be differentiated from the "random 
prompt and accept" use case. I would rather think through recommendations 
around the user trust decision to accept a certificate. It clearly 
violates safe staging the way it is presented today (what basis does the 
user have to accept such a certificate?). Why not use the certificate for 
the encryption but not the authentication (until the user has some reason 
to make an authentication decision)? 





"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com> 
Sent by: public-wsc-wg-request@w3.org
05/15/2007 04:29 PM

To
"public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
cc

Subject
ACTION-209: What is a secure page?







Hello all,

I have just put my proposals about "what a secure page is" on the Wiki

http://www.w3.org/2006/WSC/wiki/WhatIsASecurePage

Some may disagree with several of the suggestions, or have doubts about 
them ever being adopted.

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************