Re: [websec] [Technical Errata Reported] RFC6797 (4075)

Tobias Gondrom <tobias.gondrom@gondrom.org> Sun, 10 August 2014 11:48 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EFB1A06ED for <websec@ietfa.amsl.com>; Sun, 10 Aug 2014 04:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.668
X-Spam-Level:
X-Spam-Status: No, score=-102.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 Se_A-ZxO_YyM for <websec@ietfa.amsl.com>; Sun, 10 Aug 2014 04:48:12 -0700 (PDT)
Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D779E1A06EA for <websec@ietf.org>; Sun, 10 Aug 2014 04:48:11 -0700 (PDT)
X-No-Relay: not in my network
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=L458J1HyEMOX9SRQbYY/snVhdojDQhj+gBqS4HmgqlABm4z1qZJFPSxXSQ83jqEs63fgPK/c0uUVuCykrdjtKl9Qvhq2ElgBiKOa7B9kEtqZ0O8XPKwjHuklSt9FugWANEIGWzsik31O/WajYXy8d570jYmhKSB6ZLOoQ4S8VZU=; h=X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type;
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
Received: from [192.168.0.6] (46-64-103-184.zone15.bethere.co.uk [46.64.103.184]) by www.gondrom.org (Postfix) with ESMTPSA id 9A57C1539004F; Sun, 10 Aug 2014 13:48:09 +0200 (CEST)
Message-ID: <53E75BF8.2060204@gondrom.org>
Date: Sun, 10 Aug 2014 12:48:08 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ynir.ietf@gmail.com
References: <20140808190533.56A431801A4@rfc-editor.org> <CALaySJJB=g_gD9rFVoLU7JW7SkVvq9bK_H71TdPq3-em0JLFfQ@mail.gmail.com> <COL131-DS14E7BAAD30061ECA07D1D5F0EE0@phx.gbl> <CALaySJJe6v7JwceN+TucqtdJWA9dh3+oj6-awYXHJwY6iZEvzA@mail.gmail.com> <151DC1A6-B162-4EF7-A78B-3723A64F7D84@gmail.com> <COL131-DS10F844603100882CC36852F0EE0@phx.gbl> <85006244-94CE-4AD8-9042-4C8CDF216C12@gmail.com> <53E75740.1060200@gondrom.org> <11E76DB3-F10C-4C1C-9720-97F590639044@gmail.com>
In-Reply-To: <11E76DB3-F10C-4C1C-9720-97F590639044@gmail.com>
Content-Type: multipart/alternative; boundary="------------080104010407040506070101"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/npTdsU0gw0oOYeekogoeWASzi1A
Cc: e_lawrence@hotmail.com, Jeff.Hodges@paypal.com, presnick@qti.qualcomm.com, websec@ietf.org, collin.jackson@sv.cmu.edu, barryleiba@computer.org
Subject: Re: [websec] [Technical Errata Reported] RFC6797 (4075)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 10 Aug 2014 11:48:13 -0000

On 10/08/14 12:40, Yoav Nir wrote:
> On Aug 10, 2014, at 2:28 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
>
>> Thanks.
>>
>> I agree, this is an "update" and not an "errata".
>>
>> However, am not sure how to best retain this information:
>> Because this is a good point for a best practice.
>> And be it only in advising the best practice when using HSTS, like
>> simply including one link to the parent https://example.com to avoid
>> having unprotected parent-domains.
> Well, if we could talk Eric into writing a draft…
>

In theory we/he could do an RFC6797bis for this.
And as the change is only small, the review period should also be
possible to keep contained.

On the other hand, personally, I am not sure a new RFC would really be
necessary, because it seems to me that with proper best practices
(declare HSTS Policy at their top-level domain + frequently include the
top-level, to make sure it's HSTS is still renewed) this can be solved
and there would be no change on the wire.

Best regards, Tobias