Review of editors draft

Hi,

Here is the result from a quick review of the editor's draft made by one  
of my collegues.

----------------------

No version of the TLS protocol that suffers known security flaws has been  
negotiated. At the point of writing of this document, versions of SSL  
prior to SSLv3 [SSLv3] MUST NOT be considered strong.

- Who decides what constitutes a security flaw? Is there a list somewhere?  
Can an organization say "We don't consider this 2^52 collsion attack to be  
feasible, so it isn't a security flaw"? The same holds for a definition of  
industry practice. Will W3C plan to publish such lists?



An HTTP transaction is strongly TLS-protected if [...] the server used a  
validated certificate [...] that has been verified by chaining up to a  
locally configured trust anchor.

What if the chain used expired certificates, or CRL or OCSP failed?  
Shouldn't the transaction be considered weak? Should the spec mention that  
browsers are encouraged to have expiry times for the locally configured  
anchors?



[Definition: An HTTP transaction is weakly TLS-protected if it is  
TLS-protected, but strong TLS protection could not be achieved for one of  
the following reasons:]

I guess the idea is that anything which isn't strong is weak, so I guess  
the spec should say that. What if Strong TLS couldn't be achieved for some  
other reason than those listed, say the protocol was unite-secure: instead  
of https:. That transaction would then neither be strong, nor weak, which  
seems a bit weird.



There is no mention of how to pin, from what time will the pinning make a  
site secure? Is it just a matter of clicking on a button the first time  
you visit a site, and then the address bar will show "BEST PROTECTION -  
FEEL FREE TO USE YOUR CREDIT CARD"? After pinning, how soon should the UI  
be updated?



When, for a TLS-protected HTTP connection, the certificate presented is  
found to have expired, error signaling of class danger (6.4.3 Danger  
Messages) MUST be used.

Please, no. This directly contradicts the idea of pinning. If I pin a  
self-signed certificate to a server, the expiry time of the certificate is  
hardly of any consequence. There should be a warning message only in such  
cases, not a danger message. The same goes for very recent expiries for a  
trust anchor, there shouldn't be a danger message when going to a third  
party URL whose CA expired yesterday, a warning will be more than  
sufficient. For such cases, it can be upgraded to a danger message after,  
say, 3 months.



Quite a few error conditions are left unspecified, e.g. chain errors, CA  
errors, CRL and OCSP errors. For us, also rootstore errors. The spec might  
have a line about how to consider additional error messages in order to be  
spec compliant.



Web user agents SHOULD inform users, using an error of class Warning or  
higher (6.4.2 Warning/Caution Messages , 6.4.3 Danger Messages), when  
navigation between TLS-secured pages involves redirects which travel over  
weakly TLS-protected, or unsecured HTTP channels.

This doesn't make any sense. Say you are on site A, which is weakly  
TLS-protected, and go to site B, which is also weakly TLS-protected, and  
site B has a redirect. Why should the browser warn the user, and against  
what? This only makes sense if part of the automated transmission is of a  
lower security level than the end-point. Warning the user is often no  
point, the user agent should have a choice of either warning the user, or  
simply showing the trust level of the lowest denominator in the UI.



Insecure form submission

The warning is no use unless it is presented to the user so the user can  
abort the action. Presenting a warning afterwards "By the way, the data  
you just submitted wasn't safe" is no use, and the spec should clarify  
this.



This [Definition: identity signal ] SHOULD be part of primary user  
interface
and
Obscuring or disabling Security User Interfaces

For instance WinMobile uses UI which disappears after a few seconds. It  
then just has a half-transparent layover in the lower right corner to  
bring the UI back up. It would thus fail on both the two terms above.  
Making a spec which goes against current popular implementations both at  
the SHOULD and the MUST level should preferably be avoided. A line in the  
spec that that such elements which purpose are not to provide any  
information, but only to give the user somewhere to click aren't  
considered chrome would suffice.



During interactions with a mixed content Web page, the identity signal  
MUST NOT include any positive indicators exceeding those in use for  
unprotected HTTP transactions.

So if on an EV page, there is some non-EV HTTPS content, the identity  
signal should display "Completely unprotected"? It should be changed from  
"unprotected" to "the least protected".



The information sources SHOULD make the following security context  
information available:
Whether the user has visited the site in the past
Whether the user has stored credentials for this site

History might be deleted, and the user agent might not know if the user  
has visited the site. What to do if the user visited the site in the past  
 from a different browser on a different computer? The line should be  
changed to "Whether history data show a previous visit", or a general line  
should be added about the browser only being responsible for what is left  
in it's history, and that it isn't required to keep any such data.
While I find an interaction with Wand interesting, it might also pose a  
few problems, and it is a brand new idea. I'd recommend MAY for that  
particular item, instead of SHOULD. For one thing, we are now mandating an  
interaction through the credentials manager (which might not always be the  
browser) and the browser. Are cookies "credentials"? Is a currently logged  
in HTTP authentication session "credentials", or do they need to be stored  
somewhere else than in browser memory? If the user just saved the  
credentials this session, do they still count?
Since there are already several MAYs there, including the brand new Wand  
interaction, I'd like to suggest one more, nickname. Bookmarks can use  
nicknames, and this is a very strong identity check for most users.



These warnings SHOULD be used if the likelihood of danger is present, but  
cannot be confirmed.

That should be a MAY. Otherwise a user agent which shows a danger message  
instead of a warning message in some particular occurence (based for  
instance on a 99.9% heuristics) will not be spec compliant.



The difference between a warning and a danger message is not clear enough.  
Both require an interruption to the user, thus making it impossible to go  
on without acting. They only difference I can see between them is that a  
warning message just requires an acknowledgement, while a danger message  
requires an interaction. I don't understand the difference. One particular  
point to consider is if the user agent may continue loading resources. For  
warnings that should (MAY) be possible, but for dangers loading should  
halt until the user approves.


For HTTPS requests caused using the XMLHttpRequest API [ref-XHR]  
[ref-XHRl2], this specification permits either handling the error situation
-> handling any error
The way it is writtin now it sounds as if XHR is an error situation.



-- 
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
********************************************************************

Received on Tuesday, 26 May 2009 18:32:19 UTC