Re: [websec] Question regarding RFC 6797

Claudio Saavedra <csaavedra@igalia.com> Tue, 29 May 2018 09:20 UTC

Return-Path: <csaavedra@igalia.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 1199D12E8B1 for <websec@ietfa.amsl.com>; Tue, 29 May 2018 02:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=igalia.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQaL17DyU15l for <websec@ietfa.amsl.com>; Tue, 29 May 2018 02:20:46 -0700 (PDT)
Received: from fanzine.igalia.com (fanzine.igalia.com [91.117.99.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9A212E8D9 for <websec@ietf.org>; Tue, 29 May 2018 02:20:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID; bh=fcM54+DhX5wMajQoQ7jHYQr0Jw4x1f2GWLwnLpo92Ec=; b=R5yaF2ThUUy1Qd+7ZMWMkkPm9qkvueF94cfXwxHEXZRgZpdKW4y0WqH0EqUGZV3dfckzufCV/+LObciaKqFxwLnmZVhWrnT6Yc+nIzWZlkelJvsexnc51nUL2Oz4Veks/xiPYyMvFaNWSHQlZ4KqXcSlZU2xYAo/uVatWhN3qhXQcjGv+hibjRgBni6wgj49Q/DT6cp8BWiBysGH4bPDY0R/ZratTrZtLBTgpUOL3TpYPmYw2UcFk4CrgYkeFh1iF4Crv0kHCamuC3KB1rDWbK7NkS77z3ivqARo4fHlLNAygqsvmHunoGSEa+7OB+9x3nno7q2vx6uXD0W8FQNITg==;
Received: from [194.100.51.2] (helo=patanjali) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1fNao5-0000WX-4V; Tue, 29 May 2018 11:20:41 +0200
Message-ID: <66ba316c85cea6690ad7bc10445783e53b8e8872.camel@igalia.com>
From: Claudio Saavedra <csaavedra@igalia.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: websec <websec@ietf.org>
Date: Tue, 29 May 2018 12:20:28 +0300
In-Reply-To: <CADnb78jCeL+HN5qvpFabN0kc1qM0HC5H9Ps2SBZFnrmn5cm5LA@mail.gmail.com>
References: <c725c551413c03e1aedbe4a562758853eaaf6be0.camel@igalia.com> <CADnb78jCeL+HN5qvpFabN0kc1qM0HC5H9Ps2SBZFnrmn5cm5LA@mail.gmail.com>
Organization: Igalia
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.2-1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/websec/6ci9KlR4n6r8-PlnVXPOBme9OJA>
Subject: Re: [websec] Question regarding RFC 6797
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 29 May 2018 09:20:48 -0000

On Mon, 2018-05-28 at 13:21 +0200, Anne van Kesteren wrote:
> On Mon, May 28, 2018 at 10:20 AM, Claudio Saavedra <csaavedra@igalia.
> com> wrote:
> > Section 8.1 states:
> > 
> >    Update the UA's cached information for the Known HSTS Host if
> > either
> >    or both of the max-age and includeSubDomains header field value
> >    tokens are conveying information different than that already
> >    maintained by the UA.
> > 
> > The way I understand this is that if a HSTS host keeps sending the
> > same
> > values to a conforming client, this should not update the
> > information
> > cached and hence the cached information will expire after max-age
> > seconds have passed since the _first_reception_ of this header.
> 
> I have a hard time reading it another way as well; if true, this
> would be a security bug.

So if this is a security bug, I'm understanding that the desired
behavior would be the one described in 11.2. What can be done in the
specification to deal with this? Can it be reworded/updated? How can we
implementors know which of the behaviors described in 8.1 or 11.2 is to
be honored?

Best regards,

Claudio