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

Eric Rescorla <ekr@rtfm.com> Fri, 29 June 2012 18:13 UTC

Return-Path: <ekr@rtfm.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 89CA821F8809 for <websec@ietfa.amsl.com>; Fri, 29 Jun 2012 11:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 oXDGZUABecmh for <websec@ietfa.amsl.com>; Fri, 29 Jun 2012 11:13:45 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F52A21F8714 for <websec@ietf.org>; Fri, 29 Jun 2012 11:13:44 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so2735533vbb.31 for <websec@ietf.org>; Fri, 29 Jun 2012 11:13:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=V02W/vsHw8ubw0VPoWcgtYLUZHtKuCCCuDJ55PT+SP4=; b=MMhTMFFzk9HeihSguMMOtr6DmiBXkERj1EYJZF0V/7X5KNKHBD73i8uqSxui58Dgi4 blVCi77ha3QXhvOWG6BKZW0OOg21pyaAUnuSWoHe9YvFtszZE8Dg9l/AFmvNL4liwVYG kLkhZG+Ieou9xe34o3y28SxDCEccpRP9aawyBxKnYu0BCpokfj4ougRqPeQ2tGC7sj+/ dr2+yCUhqRNuPRagNs2Of/D+bQ9j7mKv4GtB9TaeyK4lZesHat3w7TLprXoTh8seijl2 eKG/EbmH7RHGc0FUVLGD2sX2rs86tWiomoYcnuv+jVPNXq5Ds7FuoaXOnkI0LsXiRwaL bz6Q==
Received: by 10.52.100.229 with SMTP id fb5mr1308885vdb.102.1340993624092; Fri, 29 Jun 2012 11:13:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.35.209 with HTTP; Fri, 29 Jun 2012 11:13:03 -0700 (PDT)
X-Originating-IP: [216.239.55.138]
In-Reply-To: <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com>
References: <4FD6E91B.2000602@KingsMountain.com> <CABcZeBM_PLDaU_MPYad9sEtKpTsR8V2naT5WjDOEccu6eyKGMg@mail.gmail.com> <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 29 Jun 2012 11:13:03 -0700
Message-ID: <CABcZeBOzYTjfSss2Ob27SKwO+rS70HaqXKAvOgNoHCcaiWr+WQ@mail.gmail.com>
To: "Steingruebl, Andy" <asteingruebl@paypal-inc.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmmrzsQ2USmxZtysWRWE+R6n2gkPOygUTC0u+OfvPM+z1X81nN+31VP8RvDfnW3IBzuoE1Q
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 18:13:45 -0000

On Fri, Jun 29, 2012 at 8:10 AM, Steingruebl, Andy
<asteingruebl@paypal-inc.com> 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?
>
> 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.

The primary concern is that HSTS is intended to have a very long
lifetime and that
is a security tradeoff, not just an operational cost tradeoff like DNS TTL.

It's not so much with existing HSTS as with something like
draft-evans-palmer-hsts-pinning.
Consider the case where I operate a site that load balances between
two certs, A and B
but I inadvertantly advertise a pin for A only. If I understand S 2.1
correctly, any
client who goes to A will get pinned and any client who goes to B will
reject the
pin (regardless of whether it's served.) If the client comes back and gets B
later, they will reject the cert.

This is not easy to detect with the kind of testing you describe.

-Ekr