Re: [wpkops] Taxonomy of Browser Behaviors - "Hard Fail", "Soft Fail" and "Reload Request"

Wayne Thayer <wthayer@godaddy.com> Tue, 29 April 2014 22:02 UTC

Return-Path: <wthayer@godaddy.com>
X-Original-To: wpkops@ietfa.amsl.com
Delivered-To: wpkops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044F21A09A9 for <wpkops@ietfa.amsl.com>; Tue, 29 Apr 2014 15:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuNWOWe94Thw for <wpkops@ietfa.amsl.com>; Tue, 29 Apr 2014 15:02:43 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id 70B931A094B for <wpkops@ietf.org>; Tue, 29 Apr 2014 15:02:42 -0700 (PDT)
Received: from CO1PR02MB064.namprd02.prod.outlook.com (10.242.163.16) by CO1PR02MB063.namprd02.prod.outlook.com (10.242.163.14) with Microsoft SMTP Server (TLS) id 15.0.929.12; Tue, 29 Apr 2014 22:02:39 +0000
Received: from CO1PR02MB064.namprd02.prod.outlook.com ([169.254.5.121]) by CO1PR02MB064.namprd02.prod.outlook.com ([169.254.5.121]) with mapi id 15.00.0929.001; Tue, 29 Apr 2014 22:02:38 +0000
From: Wayne Thayer <wthayer@godaddy.com>
To: "ben@digicert.com" <ben@digicert.com>, "wpkops@ietf.org" <wpkops@ietf.org>
Thread-Topic: [wpkops] Taxonomy of Browser Behaviors - "Hard Fail", "Soft Fail" and "Reload Request"
Thread-Index: Ac9j3Q10HtNKjLCHSyqk1X1AnOH2awAGGE+g
Date: Tue, 29 Apr 2014 22:02:37 +0000
Message-ID: <93c43a17f6194fdeb2df96d25188090e@CO1PR02MB064.namprd02.prod.outlook.com>
References: <029801cf63dd$0f484330$2dd8c990$@digicert.com>
In-Reply-To: <029801cf63dd$0f484330$2dd8c990$@digicert.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.202.160.225]
x-forefront-prvs: 0196A226D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(377454003)(189002)(199002)(74502001)(80976001)(76576001)(19300405004)(99286001)(46102001)(19580395003)(19580405001)(92566001)(83322001)(31966008)(101416001)(81542001)(74662001)(86362001)(99396002)(74316001)(81342001)(83072002)(33646001)(87936001)(2656002)(80022001)(20776003)(66066001)(79102001)(15202345003)(16236675002)(50986999)(85852003)(77982001)(76176999)(15975445006)(19609705001)(54356999)(4396001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB063; H:CO1PR02MB064.namprd02.prod.outlook.com; FPR:AFE6F4FC.A412C311.FED17D77.49E9F041.20454; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (: godaddy.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_93c43a17f6194fdeb2df96d25188090eCO1PR02MB064namprd02pro_"
MIME-Version: 1.0
X-OriginatorOrg: godaddy.com
Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/6GUW1ynkv6XJVBe8mgeSB_G0EDU
Subject: Re: [wpkops] Taxonomy of Browser Behaviors - "Hard Fail", "Soft Fail" and "Reload Request"
X-BeenThere: wpkops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <wpkops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpkops>, <mailto:wpkops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/wpkops/>
List-Post: <mailto:wpkops@ietf.org>
List-Help: <mailto:wpkops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpkops>, <mailto:wpkops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Apr 2014 22:02:47 -0000

Ben,

In the context of revocation, 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" response without any indication to the user.

Also, I think of revocation "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", "Soft Fail" and "Reload Request"

In working on the next version of the Certificate Processing document, I have come across two different uses of "hard fail."   I am also concerned that use of the phrase, "soft fail," might encounter similar problems.  Also I've seen "Retry" or "Reload" messages,  which are hard fail, but with an option to try loading again.

I've seen "hard fail" used (1) when referring to a session that is stopped because of certificate revocation, where the user is prevented from proceeding, and also (2) when referring to 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 because 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) session negotiation and drops the connection or otherwise blocks the user from continuing (also referred to as "hard fail")."  However, 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 negative visual indicator or a "downgrade" of security indicators like removal of the lock icon, removal of EV indication, etc., are not "soft fail."  I hope that everyone agrees.)

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

For "hard fail," here is what I've seen:

[Error Message]
Firefox - "Fix connection problems"
Opera - "This webpage is not available"
Chrome - "This webpage is not available"
Internet Explorer - "IE cannot display the 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,  here are some of the buttons provided for a variety of different conditions, such as invalid certificates:

[Error Message]

Firefox - "Get me out of here" "Technical Details" "I understand the risks"
Safari - "Show Certificate" "Cancel" "Continue"
Internet Explorer - "Click here to close" ""Continue to this website (not recommended)" "More Information"
Chrome - "Proceed anyway" or  "Back to safety"  and "Help me understand"

Opera - "Show Certificate"  "Continue Anyway" and "Cancel" or "Back to Safety"

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"
Firefox - "Try again"

Thanks,
Ben