Re: [websec] Showing errors in HSTS
Alexey Melnikov <alexey.melnikov@isode.com> Tue, 10 April 2012 11:32 UTC
Return-Path: <alexey.melnikov@isode.com>
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 CE7DD21F850D for <websec@ietfa.amsl.com>; Tue, 10 Apr 2012 04:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.866
X-Spam-Level:
X-Spam-Status: No, score=-101.866 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 XAdbzLxMYvcZ for <websec@ietfa.amsl.com>; Tue, 10 Apr 2012 04:32:40 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 13F6421F846A for <websec@ietf.org>; Tue, 10 Apr 2012 04:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334057525; d=isode.com; s=selector; i=@isode.com; bh=cXXD58AiFRHcL5/H2kD0Gl1MzUhPxN130Wh5xzI5Hko=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=oHMf1CsGx1OQoV7IFHWAgYMZoLIYupO3NUro1Aa3MX2J8q1qW3mU7wSDXF1fsRXTwgslmY EgGSNaWFM2Nkr4xPb89yiKihUGVAFusEPHYrWo+F0HgEJAJ/h74UT7+KU9fIWXsGYxTsGZ QFpNm3Wq9sg6DwrmpZURh+eBnpkGUFk=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <T4QaNAAg273-@rufus.isode.com>; Tue, 10 Apr 2012 12:32:05 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F82C6F9.1070007@isode.com>
Date: Mon, 09 Apr 2012 12:24:41 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <4F7B5D18.1040407@isode.com> <9D4DE4DF-DAF6-4C91-B699-BC71FC4C36B0@vpnc.org>
In-Reply-To: <9D4DE4DF-DAF6-4C91-B699-BC71FC4C36B0@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [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: Tue, 10 Apr 2012 11:32:40 -0000
On 04/04/2012 13:38, Paul Hoffman wrote: > 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. I am not a big fan of "things unmentioned are Ok", especially after the topic was explicitly discussed in Paris. I think we will make a service to implementors by being explicit on this.
- [websec] Review of draft-ietf-websec-strict-trans… Alexey Melnikov
- [websec] Showing errors in HSTS Paul Hoffman
- Re: [websec] Showing errors in HSTS Tobias Gondrom
- Re: [websec] Showing errors in HSTS Alexey Melnikov
- Re: [websec] Review of draft-ietf-websec-strict-t… =JeffH
- Re: [websec] Review of draft-ietf-websec-strict-t… Peter Saint-Andre
- Re: [websec] Review of draft-ietf-websec-strict-t… Alexey Melnikov
- Re: [websec] Review of draft-ietf-websec-strict-t… Alexey Melnikov
- Re: [websec] Review of draft-ietf-websec-strict-t… Peter Saint-Andre
- Re: [websec] Review of draft-ietf-websec-strict-t… =JeffH