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

"Ben Wilson" <ben@digicert.com> Tue, 29 April 2014 18:58 UTC

Return-Path: <ben@digicert.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 78B0A1A097A for <wpkops@ietfa.amsl.com>; Tue, 29 Apr 2014 11:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.252
X-Spam-Level:
X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 jvuFN0ljr9Q8 for <wpkops@ietfa.amsl.com>; Tue, 29 Apr 2014 11:58:56 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 08D101A0979 for <wpkops@ietf.org>; Tue, 29 Apr 2014 11:58:56 -0700 (PDT)
Received: from BWILSONL1 (unknown [67.137.52.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id A79F37FA38D for <wpkops@ietf.org>; Tue, 29 Apr 2014 12:58:54 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1398797934; bh=1edtvrb1A0Mq2ZNq3MRGEnecMXRBXUiY+wct5WnCNho=; h=Reply-To:From:To:Subject:Date; b=xdGmUS0TiM58tGjSCaSfe4NADy7bIfMlVgDH5FCobhnX67BJgeiSPVT9jWzCTnYtM L9zQDSgE3QCLE5bhTJukFMSPigwbSdM8EIy67A0nptF2cN0252OM3VWFlE9v2uk0vj E1J53jTDiSBkK08+Brz9d6DGCEafBtbccTyohJkE=
From: Ben Wilson <ben@digicert.com>
To: wpkops@ietf.org
Date: Tue, 29 Apr 2014 12:58:50 -0600
Organization: DigiCert
Message-ID: <029801cf63dd$0f484330$2dd8c990$@digicert.com>
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac9j3Q10HtNKjLCHSyqk1X1AnOH2aw==
Content-Language: en-us
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0290_01CF63AA.C4271700"
Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/EQkgBpY13Vr5zynJO4f5WxJiSIw
Subject: [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
Reply-To: ben@digicert.com
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 18:58:58 -0000

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