Re: [websec] Showing errors in HSTS

Tobias Gondrom <tobias.gondrom@gondrom.org> Mon, 09 April 2012 10:35 UTC

Return-Path: <tobias.gondrom@gondrom.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 704EB21F8609 for <websec@ietfa.amsl.com>; Mon, 9 Apr 2012 03:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.778
X-Spam-Level:
X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 d6kN07n5q7VE for <websec@ietfa.amsl.com>; Mon, 9 Apr 2012 03:35:52 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7887A21F864D for <websec@ietf.org>; Mon, 9 Apr 2012 03:35:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Hv42WUu1gANvPxkwFz+tinELKsoeoRN0dkZE0S3WhvyLCLwmoQ+yAwUwFG4TwgOjbbj2OuJv3P4pBKwYPWneG+glfJxtBumIix/r4IvnptIck36c8XSxaCvOjY3CbB5T; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 19558 invoked from network); 9 Apr 2012 12:35:42 +0200
Received: from n2028211917.imsbiz.com (HELO ?10.65.1.73?) (202.82.119.17) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Apr 2012 12:35:41 +0200
Message-ID: <4F82BB79.5050706@gondrom.org>
Date: Mon, 09 Apr 2012 18:35:37 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: 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>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 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: Mon, 09 Apr 2012 10:35:52 -0000

<hat="individual">
I agree with Paul, no need to specify more clearly here what is not 
prohibited.
Best regards, Tobias


On 04/04/12 20: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.
>
> --Paul Hoffman
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec