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

"Steingruebl, Andy" <> Fri, 29 June 2012 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89CAD21F86A6 for <>; Fri, 29 Jun 2012 08:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.117
X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qtixvk6fJ-ZP for <>; Fri, 29 Jun 2012 08:10:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AD7C121F8615 for <>; Fri, 29 Jun 2012 08:10:49 -0700 (PDT)
DomainKey-Signature: s=ppinc;; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=KyeGTPskRlC/JtvSmFPbL8JlqNWPFPkKGOo1h/GnxO+XyqeDp7icLb64 U2H0q/sRAhCB53cwhTHDsY0N1zRiE9i9s3+DeLfCB+3kEV2RjT3cdgkzJ GqKYINTmhtL8B11;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=ppinc; t=1340982650; x=1372518650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BrKeWLaEvoaFJkD+ipZH8/Y7ADCWLzqdGaCQIwu2kEc=; b=UmI0+z+TfCtnRsebZQLuq6MhoCIWWhay/4hLO/cdZh99NpBj+Gr6bPgF d7zjPrH5gkn7XzG9tsBJaZLWaN6sI+xq7d/sJyP8Il7ux/juV5OmWNH5x WpyKW//elS7J3LA;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.77,498,1336374000"; d="scan'208";a="8389034"
Received: from (HELO ([]) by with ESMTP; 29 Jun 2012 08:10:49 -0700
Received: from ([fe80::40c1:9cf7:d21e:46c]) by ([fe80::a487:c570:9abc:bb59%14]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 09:10:42 -0600
From: "Steingruebl, Andy" <>
To: Eric Rescorla <>, =JeffH <>
Thread-Topic: [websec] Issue #41 add parameter indicating whether to hardfail or not
Thread-Index: AQHNSGkgYOV2ID/j0kWG8soUgCgtdpcR2vAA//+l9xA=
Date: Fri, 29 Jun 2012 15:10:42 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: Y2Ln0gToo+qeHmM0WHRC5Q==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: IETF WebSec WG <>
Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jun 2012 15:10:57 -0000

> 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?  

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.  

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.

- Andy