Sub= ject:	[T17Q11] Trust anchor information
Dat= e:	Mon, 7 Apr 2014 09:09:41 +0200
Fro= m:	Erik Andersen <era@x500.eu>
To:=	Directory list <x500standard@freelists.org>, SG17-Q11 <T13sg17q11@lists.itu.int>
CC:=	SG17-Q10 <t13sg17q10@lists.itu.int>

Sub= ject:

[T17Q11] Trust anchor information

Dat= e:

Mon, 7 Apr 2014 09:09:41 +0200

Fro= m:

Erik Andersen <era@x500.eu>

To:=

Directory list <x500standard@freelists.org>, SG17-Q11 <T13sg17q11@lists.itu.int>

CC:=

SG17-Q10 <t13sg17q10@lists.itu.int>

Ben,=

In the context of revo= cation, I have a different concept of the terms “soft fail” and= “hard fail” than what you describe below. I think of soft fail= as a scenario where a browser checks OCSP, does not receive a response, and proceeds as if it had received a “good” respon= se without any indication to the user.

Also, I think of revoc= ation “hard fail” as the scenario you describe below as “= soft fail” where the browser presents a blocking error that the user = can then choose to bypass.

Thanks,

Wayne

From: wpkops [mailto:wpkops-bounces@ietf.org]= On Behalf Of Ben Wilson
Sent: Tuesday, April 29, 2014 11:59 AM
To: wpkops@ietf.org
Subject: [wpkops] Taxonomy of Browser Behaviors - "Hard Fail&qu= ot;, "Soft Fail" and "Reload Request"

In working on the next version of the Certificate Pr= ocessing document, I have come across two different uses of “hard fai= l.” I am also concerned that use of the phrase, “so= ft fail,” might encounter similar problems. Also I’ve see= n “Retry” or “Reload” messages, which are hard fail, but with an o= ption to try loading again.

I’ve seen “hard fail” used (1) whe= n referring to a session that is stopped because of certificate revocation,= where the user is prevented from proceeding, and also (2) when referring t= o intentional client behavior when encountering other problems with the certificate that indicate it is not trustworthy. (= I suppose it could also mean a crash or other unintentional behavior becaus= e of a bug in code.) With respect to (2), I have called this a “= ;fatal error” - A behavior in which the browser detects an abnormal condition and halts (or technically cannot complete) s= ession negotiation and drops the connection or otherwise blocks the user fr= om continuing (also referred to as “hard fail”).” H= owever, in Phill’s paper on revocation behavior, he uses “hard fail”, too.

I have used the term “bypassable error” = instead of “soft fail”, defined as “behavior in which the= browser detects an abnormal condition and asks the user whether to proceed= with (i.e. click-through to) the SSL/TLS connection.” Is this the same as “soft fail”? (I’m assuming that a nega= tive visual indicator or a “downgrade” of security indicators l= ike removal of the lock icon, removal of EV indication, etc., are not ̶= 0;soft fail.” I hope that everyone agrees.)

Any thoughts? Does it matter what kind of R= 20;next step” is provided in the dialogue presented to the user? = ; For instance, the distinction between hard and soft fail might be as simp= le as whether the error window lacks or contains buttons or links that allow the user to proceed toward making the SSL/TLS connecti= on.

For “hard fail,” here is what I’ve= seen:

[Error Message]

Firefox - “Fix connection problems”

Opera – “This webpage is not available&#= 8221;

Chrome – “This webpage is not available&= #8221;

Internet Explorer – “IE cannot display t= he webpage” “What you can try: Diagnose Connection = Problems”

Internet Explorer – “This page cannot be= displayed. Fix connection problems”

In looking at soft fail / bypassable errors, h= ere are some of the buttons provided for a variety of different conditions,= such as invalid certificates:

[Error Message]

Firefox – “Get me out of here” = 220;Technical Details” “I understand the risks”

Safari – “Show Certificate” “= ;Cancel” “Continue”

Internet Explorer – “Click here to close= ” ““Continue to this website (not recommended)” = 220;More Information”

Chrome - “Proceed anyway” or ̶= 0;Back to safety” and “Help me understand”

Opera – “Show Certificate” &= #8220;Continue Anyway” and “Cancel” or “Back to Saf= ety”

A third option I’ve noticed is a “reload= request”, which I think is different than a bypassable error or hard= fail. Am I right?

Here are some messages:

Chrome - “More” or “Reload&#= 8221;

Firefox – “Try again”

Thanks,

Ben