Re: [websec] HSTS: max-age=0 interacting with includeSubdomains

Tobias Gondrom <tobias.gondrom@gondrom.org> Tue, 21 August 2012 21: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 664F821F875C for <websec@ietfa.amsl.com>; Tue, 21 Aug 2012 14:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.189
X-Spam-Level:
X-Spam-Status: No, score=-96.189 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecB51j6IXdmW for <websec@ietfa.amsl.com>; Tue, 21 Aug 2012 14:35:20 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6C74921F8757 for <websec@ietf.org>; Tue, 21 Aug 2012 14:35:20 -0700 (PDT)
Received: (qmail 9551 invoked from network); 21 Aug 2012 23:35:18 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.65?) (94.194.102.93) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 21 Aug 2012 23:35:18 +0200
Message-ID: <5033FF14.2060301@gondrom.org>
Date: Tue, 21 Aug 2012 22:35:16 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jeff.Hodges@KingsMountain.com
References: <5033E5A5.3020205@KingsMountain.com>
In-Reply-To: <5033E5A5.3020205@KingsMountain.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: websec@ietf.org
Subject: Re: [websec] HSTS: max-age=0 interacting with includeSubdomains
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: Tue, 21 Aug 2012 21:35:21 -0000

On 21/08/12 20:46, =JeffH wrote:
> Tobias replied:
> >
> > I replied:
> >
> >> Tobias wrote
> >>
> >> > Look at it in reverse order:
> >> > 1. We visit https://sub.example.com and receive HSTS with
> >> > max-age=1234567890
> >> > 2. We visit https://example.com and receive HSTS with max-age=0 ;
> >> > includeSubdomains
> >> >
> >> > as far as I remember that would actually clear HSTS for
> >> > sub.example.com?
> >>
> >> No, it would not do so.  As Adam said, the user agent maintains a list
> >> of distinct host names which have issued the HSTS Policy (aka STS
> >> header field).
> >>
> >> The above scenario would result in no entry for example.com, and an
> >> entry for sub.example.com
> >
> > Fine by me. Am just wondering on whether this is unambiguous enough 
> from
> > the draft?
> > Do we need to be more clear on that? Or did I miss a clarifying 
> point on
> > that somewhere in the draft?
>
> well, there's also the normative text about this in Section 8.1 
> "Strict-Transport-Security Response Header Field Processing". But 
> there's no forward reference to it from S 6.1.x.
>
> I'll try to fix that, see below.

<hat="individual">
well, I read section 8.1 before, too. Actually I re-read the whole ID in 
search of a sentence making a statement about how to handle this 
particular case above, but couldn't find any. So I don't think this is 
about forward reference. The question is, is it specified somewhere in 
the ID already and I just missed it (in which case it may be ok to just 
leave everything as is) or is it not specified in the draft, yet? (in 
which case it would make sense to add something, whether in section 8 or 
6 - with or without forward reference...)

>
>
> > Specifically my confusion came when reading 6.1.1 and 6.1.2 and trying
> > to apply them as:
> >
> > first 6.1.1.: "A max-age value of zero (i.e., "max-age=0") signals 
> the UA to
> >            cease regarding the host as a Known HSTS Host."
> > and then the next sentence in 6.1.2. "..."includeSubDomains" directive
> > is a valueless flag which,
> >     if present, signals to the UA that the HSTS Policy applies to this
> > HSTS Host as well as any subdomains"
> >
> > Could that be misread as "0" means cease HSTS and then
> > "includeSubDomains" extends that meaning to all subdomains?
>
> no, that's not how it's supposed to work, but like I said above, the 
> normative text is in section 8.1.

Didn't find that information on how to handle this particular case in 
section 8.1. Could you maybe point me to the paragraph or copy&paste on 
max-age=0 and includeSubDomain, in case I am ignorant/blind/stupid/can't 
find it....

>
> So, I've made some updates in my -13 working copy to try to polish 
> this out a bit...
>
> ###
>
> 6.1.1.  The max-age Directive
>
>    The REQUIRED "max-age" directive specifies the number of seconds,
>    after the reception of the STS header field, during which the UA
>    regards the host (from whom the message was received) as a Known HSTS
>    Host. ...
>
>    NOTE:  A max-age value of zero (i.e., "max-age=0") signals the UA to
>           cease regarding the host as a Known HSTS Host, including the
>           includeSubDomains flag (if set for that HSTS Host).  See also
>           Section 8.1 "Strict-Transport-Security Response Header Field
>           Processing".
>
> ...
>
> 8.1.  Strict-Transport-Security Response Header Field Processing
>
>    ...
>
>       The max-age value is essentially a "time to live" value relative
>       to the reception time of the STS header field.
>
>       If the max-age header field value token has a value of zero, the
>       UA MUST remove its cached HSTS Policy information (including the
>       includeSubDomains flag if set) if the HSTS Host is known, or, MUST
>       NOT note this HSTS Host if it is not yet known.
> ...
>
> ###
>
> note the now-explicit mention of treatment of the includeSubDomains 
> flag in the above excerpts.
>
> Does that help clarify things ?

Actually, the proposed text does not clarify it at all in my understanding.
Maybe I did not make my point clear enough:
the case in question is: does HSTS with max-age=0 and includeSubDomains 
mean you remove the HSTS flag (entry) for the subDomains as well (i.e. 
is this equivalent to receiving HSTS headers with max-age=0 for all 
subdomains)? You said "no" and that would be ok for me, but from the 
text you proposed this would still not be clear to me.

Do you see what I mean?

Tobias

>
>
> =JeffH
>
>