Re: [websec] Issue #41 add parameter indicating whether to hardfail or not

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 29 June 2012 16:24 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 C407421F877E for <websec@ietfa.amsl.com>; Fri, 29 Jun 2012 09:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.014
X-Spam-Level:
X-Spam-Status: No, score=-103.014 tagged_above=-999 required=5 tests=[AWL=-0.415, 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 aLoMQOryEhbt for <websec@ietfa.amsl.com>; Fri, 29 Jun 2012 09:24:57 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 99E3121F8781 for <websec@ietf.org>; Fri, 29 Jun 2012 09:24:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340987096; d=isode.com; s=selector; i=@isode.com; bh=vGAUQ+NzIgstrd2/vqMCdfyvSiAMJlQ73XxJJDAPLAU=; 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=QJTCFkzysUCifjWNsVLSfD2OYfL6RJm8dOhnOlnMNsJKjfy/jInDP84MoExblqDSwRYOJV yPhn9dcB1siMf1vrFVZw1UGLO/7jGPvLRTu5x0N6E7NT92whpSYvggncuoZe3zLS2kdoXo 0U0Kn87SdxtDr4N10BIQgAWvXyUD0h8=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <T-3W1wBPiDm5@statler.isode.com>; Fri, 29 Jun 2012 17:24:56 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4FEDD6D6.3070803@isode.com>
Date: Fri, 29 Jun 2012 17:24:54 +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: "Steingruebl, Andy" <asteingruebl@paypal-inc.com>
References: <4FD6E91B.2000602@KingsMountain.com> <CABcZeBM_PLDaU_MPYad9sEtKpTsR8V2naT5WjDOEccu6eyKGMg@mail.gmail.com> <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com>
In-Reply-To: <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com>
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] Issue #41 add parameter indicating whether to hardfail or not
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: Fri, 29 Jun 2012 16:24:58 -0000

On 29/06/2012 16:10, Steingruebl, Andy wrote:
>> The point of "this is testing" is  the opposite: people who can't talk to you because you've configured HSTS in a way inconsistent with your
>> actual site posture.
>> -Ekr
> Can you give us an example of how/where you think this could occur and how it is distinct from other ways you could using existing technology kill your site?

Maybe this is not a good example, but I am thinking that something like 
OCSP retrieval failing on the client side is not something that would 
show up in the webserver logs.

> As an admittedly snarky example you could easily public a bad A record in DNS and you'd never see any traffic at all, but there isn't a "test new A record flag" or "test new MX server" flag in the DNS.

There is however "I am testing DKIM" flag published in DNS.

> We assume that as part of deploying HSTS people do some basic checks like make sure their website actually responds over HTTPS and generates webserver logs, and they know which domain they are publishing HSTS records for.
>
> Some specifics would help me a lot to understand the concerns.