Re: ACTION-389: Error levels?

We experienced several OCSP related difficulties back in Opera 8.5+ when  
we made a failure to get a valid OCSP response a fatal error (equivalent  
to revoked), to the extent that we added a preference to disable OCSP in  
succeeding 8.x releases, and in 9.x we just downgraded the security level  
by one (to two).

This problem, which was not due to an OCSP server going offline, but  
instead returning "unauthorized" or other errors, happened several times  
over many months, the problems many times taking weeks to be resolved.  
IIRC these episodes did lead the CAs in question to implement better  
checking of the OCSP repositories.

I can't recall having seen more than one or two OCSP problems since, but  
as we now just remove the padlock, we might not get as many reports about  
such problems.


On Tue, 19 Feb 2008 00:14:55 +0100, Serge Egelman <egelman@cs.cmu.edu>  
wrote:

>
> Okay, I think I agree with you about this example.  I have no idea how
> frequently certificate status is unavailable.  I would certainly put  
> SSCs in
> bucket one due to their prevalence, and if certificates with unknown  
> status
> are as prevalent, they certainly belong there too.
>
> serge
>
> -----Original Message-----
> From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]  
> On
> Behalf Of Stephen Farrell
> Sent: Monday, February 18, 2008 1:38 PM
> To: Serge Egelman
> Cc: W3C WSC Public
> Subject: Re: ACTION-389: Error levels?
>
>
>
> I think I like the 3 categories, but would put lack of
> cert status info into bucket 1 since its often not
> available.
>
> Would also be interested in more examples - I guess the
> concern would be that one of the buckets might overflow
> which'd devalue the categorisation.
>
> S.
>
> Serge Egelman wrote:
>> Well, the idea is to create three buckets of risks:
>>
>> 1) Things that *could* be bad, but we really don't have sufficient
> evidence
>>
>> 2) Things that are *likely* bad, but we're not absolutely positive so we
>> can't block the page outright.  More importantly, this category exists
>> because we don't want to habituate users to the most severe warnings by
>> showing them in situations where there are likely to be false positives
>> (e.g. determinations made solely by heuristics or when not enough
>> information is known, but there is sufficient information to raise
>> concern).
>>
>> 3) Things that are *known* to be bad.  These warnings appear only when a
>> real threat has been identified.  These warnings must not be shown when
>> there is a chance of false positives, as this will habituate the users
>> to these warnings and they will become useless in all other cases.
>>
>> Thus, I think that heuristics and a CRL which can't be located would
>> both fall into the middle category.  These are both things that should
>> raise some concern, however we cannot be confident that something bad is
>> going to happen.
>>
>>
>> serge
>>
>> Stephen Farrell wrote:
>>>
>>>
>>> Text looks good, but I think more/other examples would help.
>>>
>>> In particular I'd not equate "missing CRL" with "phishing
>>> heuristic triggered," but I guess we can discuss that sometime,
>>>
>>> S.
>>>
>>> Serge Egelman wrote:
>>>>
>>>> Here's the proposed text (I know it could use some work, but this is
>>>> a first pass), though I'm not sure which section to put it in:
>>>>
>>>> Browser security indicators MUST fall into one of the following
>>>> categories:
>>>>
>>>> 1) Notifications/Status Indicators
>>>>   a) WHAT: warnings/indicators that are displayed in the browser's
>>>> persistent primary chrome. These indicators MUST NOT force user
>>>> interaction (e.g. forcing the user to click a button to continue the
>>>> primary task).  They MUST be located in the browser's chrome and
>>>> include a succinct textual description of their meaning.
>>>> b) WHEN: the browser cannot accurately determine a security risk
>>>> based on the current security context information available.  These
>>>> indicators SHOULD also be used for situations where the risk level
>>>> may vary based on user preference.
>>>>
>>>> 2) Warning/Caution Messages
>>>>   a) WHEN: these MUST be used when the system has good reason to
>>>> believe that the user may be at risk based on the current security
>>>> context information, but a determination cannot positively be made
>>>> (e.g. CRL cannot be located, OCSP server unresponsive, phishing
>>>> heuristics triggered).  These warnings SHOULD be used if the
>>>> likelihood of danger is present, but cannot be confirmed.
>>>>   b) WHAT: these warnings MUST be designed to interrupt the user's
>>>> current task, such that the user must acknowledge the warning.  The
>>>> headings of these warnings MUST include the words "warning" or
>>>> "caution," and they MUST NOT include technical jargon, or be longer
>>>> than a dozen words.  The headings of these warnings MUST be the locus
>>>> of attention, and the warning SHOULD have an option for advanced
>>>> users to request a detailed description of the warning condition.
>>>> These warnings MUST provide the users with options on how to proceed
>>>> (i.e. the warnings MUST NOT use a single option to dismiss the
>>>> warnings and continue).  The options presented on these warnings MUST
>>>> be descriptive to the point that their meanings can be understood in
>>>> the absence of any other information contained in the warning.  These
>>>> warnings SHOULD include one recommended option, and a succinct text
>>>> component denoting which option is recommended.  In the absence of a
>>>> recommended option, the warning MUST present the user with a method
>>>> of finding out more information (e.g. hyperlink, secondary window,
>>>> etc.) if the options cannot be understood.
>>>>
>>>> 3) Danger Messages
>>>>   a) WHAT: These warnings MUST be designed such that the user's task
>>>> is interrupted, and the user is unable to view or interact with the
>>>> destination website.  The headings of these warnings MUST include the
>>>> word "danger," and they MUST NOT include technical jargon, or be
>>>> longer than a dozen words.  The heading MUST be the locus of
>>>> attention, and the warning SHOULD have an option for advanced users
>>>> to request a detailed description of the warning condition.
>>>>   b) WHEN: these MUST be used when there is a positively identified
>>>> danger to the user (i.e. not merely risk).  Examples include websites
>>>> or software downloads that have been blacklisted (i.e. positively
>>>> identified), revoked certificates, etc.
>>>>
>>>>
>>>
>>
>
>



-- 
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 Monday, 18 February 2008 23:30:45 UTC