Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps

[Benjamin Kaduk <[e-mail]>]

Hi Yakov,

Thanks for the extra comments; some notes inline.

On Sun, Jul 12, 2020 at 08:14:33PM -0400, Yakov Shafranovich wrote:
> On Tue, Jun 30, 2020 at 6:25 PM Benjamin Kaduk <[e-mail]> wrote:
> >
> > I'm happy to see the updates in the -09 that addressed most of the
> > discussion and feedback that came out of the IETF LC.  What follows are my
> > takeaways from the last call and discussion of what seems left to do before
> > the document can progress to IESG Evaluation.
> >
> 
> Before commenting on specific issues, I would like to thank Ben and
> all of the IETF members who contributed to the discussion of our
> draft. It is much appreciated. Specific comments appear in line below.
> 
> > One recurring concern during the IETF LC was that deployments of this
> > mechanism would fail to get updated, eventually becoming so stale so as to
> > be harmful.  I'm happy to see the addition of the "Expires" directive that
> > mitigates this risk, but I think we should make its presence required, and
> > additionally give some guidance that the expiration date should not be "too
> > far" into the future, perhaps capping it (at a "RECOMMENDED" level) to at
> > most a year in the future.  (Note that Section 6.2 has a bit of text that
> > assumes Expires is not mandatory, in addition to the field definition in
> > Section 3.5.5.)
> >
> 
> I think that makes sense, I am adjusting the language in the -10 draft
> to match. I assume the one year recommendation is in line with what is
> being currently done for TLS certificates?

It was chosen pretty arbitrarily when I wrote it, actually :)
But the underlying reasons for needing to refresh things periodically are
similar between the two cases, so in some sense you found the right reason.

> > Similarly, the refocusing on having the file be targeted at humans allows
> > for us to reiterate that human judgment is key in deciding when to use the
> > contents of a security.txt file vs. seeking other reporting mechanisms.
> > This applies for old/expired files, of course, but also to the recurring
> > topic of reporting compromise vs. reporting vulnerability.  When reporting
> > compromise, extra caution is needed, and there is probably some more that
> > can be said in Section 6.1 (see next paragraph).
> >
> > The topic of use for reporting compromise vs. vulnerability was raised by
> > many reviewers, to the extent that it seems like it would be very
> > challenging to craft text that would definitively convince the reader to not
> > use the contents of the files for reporting cases of active compromise, or
> > even cases of vulnerability that would easily lead to active compromise.
> > Given that Section 1.1 is entitled "Motivation, Prior Work and Scope", it
> > seems like a very good place to put a notice that "reporting compromised
> > resources (e.g., web sites) is related to, but distinct from, reporting
> > security vulnerabilities; the mechanism defined in this document is intended
> > for reporting vulnerabilities.  If it is used to report cases of active
> > compromise, or vulnerabilities that would lead to compromise of the
> > system(s) involved in this mechanism, additional considerations apply, as
> > discussed in Section 6.1".  To expound on the nature of these considerations
> > a bit more, when there is (the possibility of) active compromise, the
> > "ambient authority" granted by finding the contents of the file at the given
> > domain or other location is no longer trustworthy.  In such cases, we should
> > expect there to be an "additional source of authority" (or "trust chain")
> > that can give a sense of confidence in the reliability of the contents
> > therein.  A PGP cleartext signature is already recommended and can be one
> > such additional source of authority (provided that there is a trust path to
> > the key that made the signature); other routes to such additional sources of
> > authority were posited in the review comments, such as putting a
> > cryptographic hash of the security.txt contents in the DNS under a DNSSEC
> > signature.  I think that requiring such an additional source of authority
> > (though not a specific mechanism thereof) would go a long way to alleviating
> > concerns of misuse of security.txt from compromised systems.  However, I'm
> > not entirely sure how practical it would be to impose such a requirement
> > given the current state of defined mechanisms.  I'm hoping to get some more
> > feedback from the community on this topic, having framed it in this way --
> > the previous discussion seemed focused on other aspects of the problem and
> > did not get very far towards a concrete resolution.  At the very least, we
> > will need more discussion that specifically in case of compromise, the
> > "additional source of authority" is the only source of authority.  I would
> > expect this text to go in Section 6.1.
> >
> 
> I am adding this to sections 1.1. and 6.1, HOWEVER, my sense of the LC
> comments is that using this file for incident response is ill advised
> and should not be done. Perhaps, we should add a disclaimer that it
> should not be used that way and leave it at that?

In some abstract sense I agree that it is ill advised, but I do not think
that any words we write will stop everyone from trying to use it for
incident response.  So I think that even if we have such a disclaimer, in
order to be doing the responsible thing we'd still need to say something
about the risks of using it for incident response and our current best
thoughts about mitigating those risks.

> > Finally, I see that (while Section 3 is clear about "MUST be accessed with
> > the 'https' scheme"), in Section 6.6 we went from "MUST use HTTPS" to
> > "should use HTTPS", and since my review of the LC discussion was
> > (unfortunately) spread out in time I have forgotten what comment prompted
> > that change.  It would probably be worth some mention of the expected
> > case(s) where HTTPS would not be used (e.g., when it's local file or other
> > non-HTTP access), to strengthen the argument for using HTTPS the rest of the
> > time.  (Possibly related to
> > https://github.com/securitytxt/security-txt/issues/177 )
> >
> 
> This was in response to Taro Kivinen's comment regarding reporting an
> expired certificate:
> https://mailarchive.ietf.org/arch/msg/last-call/C3MHndMJDDVNVdLQm6y57iPr79g/

Ah, thank you for jogging my memory.

> I am changing the text below that to read:
> "In cases where the "security.txt" file cannot be served via HTTPS
> (such as being located in a filesystem or served from localhost) or is
> being served with an invalid certificate, additional human triage is
> recommended since
> the contents may have been modified while in transit."

Thanks, that looks to give a good picture of the relevant considerations.

> >
> > Some other minor comments from the IETF LC that may be worth addressing:
> >
> > David Rogers pointed out that by creating a semi-automatable
> > .well-known/security.txt mechanism, we may be implicitly disincentivizing
> > public-facing pages like /security that give more robust information or are
> > accessible to a wider audience.  A disclaimer that there is not intent to
> > discourage such publicly navigatable pages could be useful.
> >
> 
> Adding a note around this
> 
> > Michael Richardson noted that the scope of contact information is/can be
> > broader than just the website hosting the file -- e.g., it would be very
> > useful to have a discoverable way to report vulnerabilities in the products
> > produced by a company, not just the company's website.  It is probably worth
> > a mention that (or disclaimer against) the scope of use is potentially
> > broader than just the immediate website hosting the file.  (This seems
> > related to https://github.com/securitytxt/security-txt/issues/185 and might
> > result in some text in Section 3.1.)
> >
> 
> I am adding a note to that effect addressing issue #185
> 
> > Mark Nottingham also had a late-breaking comment about the .well-known
> > namespace being "registration required" (and security.txt.sig not being
> > proposed for registration), suggesting that we add a note to remind people
> > about this (https://github.com/securitytxt/security-txt/issues/188).
> >
> 
> Will do
> 
> >
> > And finally, a few additional comments from reading the -09:
> >
> > Section 3
> >
> >    "field-name" in section 3.6.8 of [RFC5322].  Fields are case-
> >    insensitive (as per section 2.3 of [RFC5234]).  The "value" comes
> >
> > nit: I think it's just the "Field names" that are case-insensitive.
> >
> 
> Can you clarify this? The way I am reading RFC5234, it sounds like any
> ABNF terminal characters are case-insensitive:
> 
> "NOTE:
>       ABNF strings are case insensitive and the character set for these
>       strings is US-ASCII."
> "

That's true for ABNF that we write ourselves, but it doesn't seem to be
true for all of the fields that we're defining.  Specifically, we use the
'uri' construction from RFC 3986 in several places, and as
https://tools.ietf.org/html/rfc3986#section-6.2.2.1 points out, in the
general case, many of the URI components are assumed to be case-sensitive.
While we could try to say something about the bits of field contents that
we do specify, it's probably easier to just talk about the Field names and
not make things too complicated.

> > Section 3.1
> >
> >    For HTTP servers, a "security.txt" file MUST only apply to the domain
> >    or IP address in the URI used to retrieve it, not to any of its
> >    subdomains or parent domains.
> >
> > [Depending on how the discussion about "product vs. website vulnerabilities"
> > resolves, this might need to grow a disclaimer that it's about the HTTP
> > resources at those domains.]
> >
> 
> As per a different comment, I am adding this text:
> "A "security.txt" file MAY also apply to products and services
> provided by the organization
> publishing the file. Implementors SHOULD use the policy directive (as
> per {{policy}})
> to provide additional details regarding scope and details of their
> vulnerability disclosure
> process."

Sounds good, thanks.

> > Section 4.1
> >
> >    Researchers should perform additional triage (as per Section 6.1) to
> >    make sure these redirects are not malicious or point to resources
> >    controlled by an attacker.
> >
> > nit: s/point/pointing/
> >
> 
> Will fix
> 
> > Section 6.6
> >
> >    (as per Section 3.4).  Also, to protect security reports from being
> >    tampered with or observed while in transit, organizations should
> >    specify encryption keys (as per Section 3.5.4) unless HTTPS is being
> >    used.
> >
> > I think we should clarify that this is "HTTPS is being used for report
> > submission".
> >
> 
> Will fix
> 
> All of the changes I am making are going into this pull request:
> https://github.com/securitytxt/security-txt/pull/192

Thanks for the pointer; I've left that tab open and will try to take a look
tomorrow/in the morning.

Thanks again for all the updates,

Ben