RE: ACTION-240 :TLS errors...

Hi Mike,

Thank you, I do understand your opinion and agree on many points
directly. May have common ground on the other points by clarifying
error conditions and processes.

Item 1 yes, web agents display security errors to security
professionals and we often have trouble with this. Does error
processing split sites that are valid and just have cert issues from
sites that are corrupted may have been compromised with some form of
malware that is breaking cert processing? Can we know for sure of why
the web server security is not functioning properly? As I have
mentioned, I have changed my opinion on how to deal with sites that are
broken due the risk of the user's system being compromised. No malware,
yes we should be able to determine some risk. If web server is broken
due to malware, users system can become compromised when page is
loaded. I suppose risk of system compromise could be added to the risk
list and user hits the button to forge ahead if they want. 

Item 2, self signed certs. I thought that some of the WSC proposals
integrated the user into trust decisions. If a user has some control to
identifying amount of trust given to a specific self signed cert I can
see a self signed cert being in the same category of a high value cert.
I may have not been clear that user trust assertions are part of the
self signed cert trust equation.


Regards,
Bill D.



-----Original Message-----
From: michael.mccormick@wellsfargo.com
[mailto:michael.mccormick@wellsfargo.com] 
Sent: Monday, July 09, 2007 12:08 PM
To: Doyle, Bill; tlr@w3.org
Cc: stephen.farrell@cs.tcd.ie; public-wsc-wg@w3.org
Subject: RE: ACTION-240 :TLS errors...

Hi Bill,

1. A current fundamental problem IMO is web agents display security
errors without providing the user with any means to interpret them from
a risk perspective.  Most users don't want to know technical details of
a TLS error; they won't to know what the risk implication is.  So I
certainly hope it's within WSC scope to make a recommendation in this
area.

2. A self-signed cert that causes an error message by definition was
not
issued by a trusted authority.  Should users trust web sites to act on
their own behalf as certificate authorities?  It's an interesting
question.  One has to keep in mind that a malicious https web site is
probably going to use a SSC.  Whereas the only reason a benign web site
should use a SSC is economic; to avoid the cost of paying money to
VeriSign et al.  Maybe the world needs a free but trustworthy CA, but
that problem is outside WSC scope.  I think we can say the presence of
a
SSC indicates somewhat higher risk than a TLS cert issued by a
reputable
trusted CA.

Mike

-----Original Message-----
From: Doyle, Bill [mailto:wdoyle@mitre.org] 
Sent: Friday, July 06, 2007 8:46 PM
To: McCormick, Mike; tlr@w3.org
Cc: stephen.farrell@cs.tcd.ie; public-wsc-wg@w3.org
Subject: RE: ACTION-240 :TLS errors...


Two things

1. I have trouble with WSC signing risk to a site. Due to the risk of
user system compromise and possible long lasting impact to the user if
site is broken the user should work risk out with help desk. If the web
server has been corrupted with malware and page allowed to load it may
be too late for the user, the users system can be taken over or
corrupted. Now that I know how easily a system compromise occurs and
this type of attack is expected to become more frequent I have changed
my mind on error processing. The site is broken, halt processing on
security error, out of band user queries help desk and figures out how
to proceed. If the help desk tells the user to proceed and users system
is compromised, it is a problem between the user and help desk.

2. maybe I read this wrong, do we have an error condition with a valid
self signed cert? If it is a trusted user site, it is perfectly valid.
User may even have a higher confidence in a self signed cert that a
high
value cert.

Bill D.


-----Original Message-----
From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of
michael.mccormick@wellsfargo.com
Sent: Friday, July 06, 2007 6:53 PM
To: tlr@w3.org
Cc: stephen.farrell@cs.tcd.ie; public-wsc-wg@w3.org
Subject: RE: ACTION-240 :TLS errors...


We should probably add something like that as an example since the
recommendation is open to interpretation (although some may prefer it
that way :).

The recommendation lists 5 requirements:

1. Allow technical user to access details of the error in a secondary
user interface (UI) but hide them in the primary UI.
2. Primary UI security context indictors should reflect the error
without displaying details.
3. Confine technical jargon to the secondary UI.
4. When user is asked to make a decision, explain the risks of each
option presented.
5. Do not refer the user to the destination URL or domain for
assistance.

Here's an imaginary example of how (IMO) a browser maker might
reasonable apply them to a self-signed server SSL cert:

 - On main window display "Security connection error".
 - Allow the page to load.
 - Adjust graphical SCIs (padlock, color bar, speedometer, etc.)
appropriately.
 - If user clicks on the main error message or SCI, pop a dialog box
with tabs for "Cause" and "Risk".
 - If user click the Risk tab, s/he sees an explanation of the risks of
browsing a site with self-signed SSL.
 - If user click the Cause tab, s/he sees technical details about the
server cert and what's suspicious about it.

Mike

-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org]
Sent: Friday, July 06, 2007 1:01 PM
To: McCormick, Mike
Cc: stephen.farrell@cs.tcd.ie; public-wsc-wg@w3.org
Subject: Re: ACTION-240 :TLS errors...

On 2007-07-05 22:37:04 -0500, michael.mccormick@wellsfargo.com wrote:

> I think what you're proposing sounds consistent with the 
> recommendations presented in
>
http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/CertErr

I'm not sure I can tell from the material in the Wiki what kind of
behavior would be expected from a self-signed certificate.  Mind
elaborating?  Or is that to be covered elsewhere?

--
Thomas Roessler, W3C  <tlr@w3.org>

Received on Monday, 9 July 2007 17:33:39 UTC