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

[Yakov Shafranovich <[e-mail]>]

Apologizes for the delayed reply

On Tue, Jul 21, 2020 at 1:41 AM Benjamin Kaduk <[e-mail]> wrote:
> 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:
>
> > > 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.
>

This is going to need some thinking - will take a look and get back to you

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

I will take a look again

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

Will watch this