Return-Path: <ynir.ietf@gmail.com>
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 138511A06F0
 for <websec@ietfa.amsl.com>; Sun, 10 Aug 2014 04:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
 SPF_PASS=-0.001] 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 NxvM70GlSo31 for <websec@ietfa.amsl.com>;
 Sun, 10 Aug 2014 04:53:01 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com
 [IPv6:2a00:1450:400c:c05::22e])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 2B1111A06EB
 for <websec@ietf.org>; Sun, 10 Aug 2014 04:53:01 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so2987681wiv.7
 for <websec@ietf.org>; Sun, 10 Aug 2014 04:52:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 
 h=content-type:mime-version:subject:from:in-reply-to:date:cc
 :message-id:references:to;
 bh=SVmqrhyBW1kXv8gpns6O8V9a2HZVd3hkyopH9Zh2iw4=;
 b=BWVYPDOvh9InWwNJm5izIxuD2Stq0TdegyaKC2lzUWhPY5ceE2ktgmLrn8ydJgUiI6
 rCaY6OejNMplC3PFAcAErewTcTO+SEvyyN5kAQ8iBH/Ls/q1U1xlMIDl+zcKpw/V1yyo
 9PktqoZeYxqAjzs9+iIJyMqnMkF2N639q4lUUo1GhY61AlrD1J1AwWf5+QA++DKzqaEk
 qOwY7iWJ0InS3ak+lz+NRPVQlD0ruOgVZbO+jmzT1pi5/fJfuq9oL8URrYlKDRSF7QzC
 MtpuxT82591lOE4UQxqSga5ErMObypvg8wY0p1nw58pIHprd3AvRkS1YRH7INbd5o1wk
 mJmw==
X-Received: by 10.194.71.52 with SMTP id r20mr2590970wju.113.1407671578260;
 Sun, 10 Aug 2014 04:52:58 -0700 (PDT)
Received: from [192.168.1.100] (bzq-84-109-50-18.red.bezeqint.net.
 [84.109.50.18])
 by mx.google.com with ESMTPSA id ko8sm31573381wjc.11.2014.08.10.04.52.56
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Sun, 10 Aug 2014 04:52:57 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_9FA85A13-79D2-42C7-9FC8-C16971587FC3"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <53E75BF8.2060204@gondrom.org>
Date: Sun, 10 Aug 2014 14:52:58 +0300
Message-Id: <E9C1EFBA-F9C6-4196-9C6B-A7F3707E7137@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>
 <53E75BF8.2060204@gondrom.org>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/Ub3gJfES_FLVv-6vbvG_JY96udQ
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:53:06 -0000


--Apple-Mail=_9FA85A13-79D2-42C7-9FC8-C16971587FC3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Aug 10, 2014, at 2:48 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> =
wrote:

> On 10/08/14 12:40, Yoav Nir wrote:
>> On Aug 10, 2014, at 2:28 PM, Tobias Gondrom =
<tobias.gondrom@gondrom.org> wrote:
>>=20
>>> Thanks.
>>>=20
>>> I agree, this is an "update" and not an "errata".
>>>=20
>>> 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=85
>>=20
>=20
> In theory we/he could do an RFC6797bis for this.=20
> And as the change is only small, the review period should also be =
possible to keep contained.=20
>=20
> 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.=20

So we get an Informational draft called =93best practices in using =
HSTS=94. 2 pages long unless we rathole and add lots of stuff.


--Apple-Mail=_9FA85A13-79D2-42C7-9FC8-C16971587FC3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Aug 10, 2014, at 2:48 PM, Tobias =
Gondrom &lt;<a =
href=3D"mailto:tobias.gondrom@gondrom.org">tobias.gondrom@gondrom.org</a>&=
gt; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">
 =20
    <meta content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3D"Content-Type">
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 10/08/14 12:40, Yoav Nir =
wrote:<br>
    </div>
    <blockquote =
cite=3D"mid:11E76DB3-F10C-4C1C-9720-97F590639044@gmail.com" type=3D"cite">=

      <pre wrap=3D"">On Aug 10, 2014, at 2:28 PM, Tobias Gondrom <a =
class=3D"moz-txt-link-rfc2396E" =
href=3D"mailto:tobias.gondrom@gondrom.org">&lt;tobias.gondrom@gondrom.org&=
gt;</a> wrote:

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">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 <a class=3D"moz-txt-link-freetext"=
 href=3D"https://example.com/">https://example.com</a> to avoid
having unprotected parent-domains.
</pre>
      </blockquote>
      <pre wrap=3D"">Well, if we could talk Eric into writing a draft=85

</pre>
    </blockquote>
    <br>
    <font face=3D"Arial">In theory we/he could do an RFC6797bis for =
this.
      <br>
      And as the change is only small, the review period should also be
      possible to keep contained. <br>
      <br>
      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. <br></font></div></blockquote><br></div><div>So we get an =
Informational draft called =93best practices in using HSTS=94. 2 pages =
long unless we rathole and add lots of stuff.</div><br></body></html>=

--Apple-Mail=_9FA85A13-79D2-42C7-9FC8-C16971587FC3--