[websec] Showing errors in HSTS

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 04 April 2012 12:38 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E8521F8656 for <websec@ietfa.amsl.com>; Wed, 4 Apr 2012 05:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.45
X-Spam-Level:
X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-f5aq13r5dF for <websec@ietfa.amsl.com>; Wed, 4 Apr 2012 05:38:33 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 882A121F864F for <websec@ietf.org>; Wed, 4 Apr 2012 05:38:29 -0700 (PDT)
Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q34CcRue045484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2012 05:38:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <4F7B5D18.1040407@isode.com>
Date: Wed, 4 Apr 2012 05:38:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D4DE4DF-DAF6-4C91-B699-BC71FC4C36B0@vpnc.org>
References: <4F7B5D18.1040407@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.1257)
Cc: IETF WebSec WG <websec@ietf.org>
Subject: [websec] Showing errors in HSTS
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 12:38:34 -0000

On Apr 3, 2012, at 1:27 PM, Alexey Melnikov wrote:

> 8.3.  Errors in Secure Transport Establishment
> 
>   When connecting to a Known HSTS Host, the UA MUST terminate the
>   connection (see also Section 11 "User Agent Implementation Advice",
>   below) if there are any errors (e.g., certificate errors), whether
>   "warning" or "fatal" or any other error level, with the underlying
>   secure transport.  This includes any issues with certificate
>   revocation checking whether via the Certificate Revocation List (CRL)
>   [RFC5280], or via the Online Certificate Status Protocol (OCSP)
>   [RFC2560].
> 
> This was discussed in Paris, but I had this in my notes already and would
> like to emphasize this: I assume that explaining the reason for the failure
> to the user (without letting the user to opt-out) is Ok? I think the document
> needs to make it clear that this is not prohibited.

Disagree. There are plenty of things that are not prohibited by this (or any other) protocol that go unmentioned. I don't see anything in this paragraph that indicates that such messages are even discouraged, so the proposed addition is unnecessary. It might be confusing, in that it will be the only place where optional messages are allowed.

--Paul Hoffman