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;
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)
Precedence: list

This is a multi-part message in MIME format.
--------------080104010407040506070101
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

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


--------------080104010407040506070101
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 10/08/14 12:40, Yoav Nir wrote:<br>
    </div>
    <blockquote
      cite="mid:11E76DB3-F10C-4C1C-9720-97F590639044@gmail.com"
      type="cite">
      <pre wrap="">
On Aug 10, 2014, at 2:28 PM, Tobias Gondrom <a class="moz-txt-link-rfc2396E" href="mailto:tobias.gondrom@gondrom.org">&lt;tobias.gondrom@gondrom.org&gt;</a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">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="moz-txt-link-freetext" href="https://example.com">https://example.com</a> to avoid
having unprotected parent-domains.
</pre>
      </blockquote>
      <pre wrap="">
Well, if we could talk Eric into writing a draft…

</pre>
    </blockquote>
    <br>
    <font face="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>
      <br>
      Best regards, Tobias<br>
      <br>
    </font>
  </body>
</html>

--------------080104010407040506070101--