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�

On Aug 10, 2014, at 2:28 PM, Tobias Gondrom <tobias.gondrom@gondrom.org&=
gt; 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=85

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...

...

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

That absolutely seems the best approach, and have it "update" 6797.  I
would love it if Eric would be a co-author, and I think we can keep
the working group going long enough to do this.

To Tobias's more general question of where we keep track of these
sorts of things when we don't have a working group to pick it up and
go with it:  Yes, that's something we've been discussing.  If we have
a former working group to work from, there's a wiki on tools.ietf.org
(websec's is at <http://trac.tools.ietf.org/wg/websec/trac/wiki>, and
it's entirely unused, but some working groups do use theirs).  I've
been suggesting that we make a habit of keeping updates, change
requests, follow-on notes, and other non-errata things there, on the
appropriate current or former WG wiki.  If there's no obvious WG, we
can use the appsawg wiki at
<http://trac.tools.ietf.org/wg/appsawg/trac/wiki> for App Area stuff.
The only bad thing about that is that there's no pointer from the RFC
to the appropriate wiki, and we've talked about establishing some sort
of per-RFC wiki also, or maybe just a per-RFC pointer to a wiki.

Barry

It sounds like you're looking for an acknowledgement of the messages. Just
to confirm, we have received this feedback, and are taking time to ensure
the replies are as considered and thoughtful as the DISCUSS points,
especially as many of these points were discussed early on and thought
addressed by the draft already.

Great; thanks, Ryan.

Yes, it's always good to at least send a "we're working on it" message
in response, especially to DISCUSS positions (as those are
specifically asking for discussion).

So we'll take this as "we're working on it, and we'll get back to
y'all when we have a good response," and thanks for confirming that.

Barry

   When used in the PKP or PKP-RO header=
s, the presence of a report-uri
   directive indicates to the UA that in the event of Pin Validation
   failure it SHOULD POST a report to the report-uri.  If the header is
   Public-Key-Pins, the UA should do this in addition to terminating the
   connection (as described in Section 2.6).
      3.  example.com can distinguish 2^N UAs by serving=
 Valid Pinning
          Headers from an arbitrary number N distinct subdomains, giving
          some UAs Valid Pinning Headers for some, but not all
          subdomains (causing subsequent requests for
          n.fingerprint.exampl=
e.com to fail), and giving some UAs no
          Valid Pinning Header for other subdomains (causing subsequent
          requests for m.finge=
rprint.example.com to succeed).

Here is a suggestion, plea=
se teak the language if I didn't get this quite right:

    =
  3.  example.com can distinguish 2^N UA=
s by serving Valid Pinning
          Headers from an arbitrary number N distinct subdomains.
          Assume in this example, Valid Pinning headers a=
re assigned
          for subdomains n.fingerprint.example.com and the includeSubDomain
          directive was intended to cover all subdoma=
ins
          m.fingerprint.exampl=
e.com. Where Valid Pinning Headers were
    =
      assigned, some were given to UAs but not for all subdomains <=
/span>causing
                    subsequent requests for <=
/span>n.fingerprint.ex=
ample.com to fail.  Valid Pinning Header are
                    not given to some UAs for=
 other subdomains, causing subsequent
          requests for m.fingerprint.example.com to succeed.
   A forensic attacker might
   find this information useful, even if the user has cleared other
   parts of the UA's state.

To:
=C2=A0 =C2=A0 =C2=A0Forensic analysis technique=
s could be used by an attacker to discern this information and
=C2=A0 =C2=A0 =C2=A0=
may find it useful, even if the user has cleared other
   parts of the UA's state.