Clarification and justification of relationship to RFC 2142

[dennypage]

I expect that here will be a number of people, like me, who will visit looking for an explanation of the relationship between this proposal and RFC 2142. What does this proposal address that RFC 2142 does not? Will this supersede RFC 2142 for security@domain? Etc. These considerations should be an intrinsic part of the draft-foudil-securitytxt submission.

[nightwatchcyber]

Looks like this would be complementary to RFC 2142. There are some instances where "security@" is controlled by the underlying hosting service unlike the web space.

Example for Google Apps: https://support.google.com/a/answer/6093413

[nightwatchcyber]

As per my comment on #35, there is a good use case where DNS or email would be better than a web-based file - where a domain has not web space like email, SIP, etc. domains.

[dennypage]

security@domain is not one of the names reserved by Google. I manage a security@domain address with Google.

I don't know of any domain hosting service that prevents effective use of security@domain.

[nightwatchcyber]

@dennypage - I am specifically referring to the case where Google Suite is hooked up to a domain name, not just domain registration. There are cases where a domain owner doesn't want Google to be CCed on these reports.

See: https://support.google.com/a/answer/33389

[dennypage]

I really don't find the Google example applicable. As previously noted, security@domain is not one of the address that Google interferes with or demands a CC of. I don't know of any domain hosting company who does.

A side note: If security@domain has published keys, the initial contact to security@domain is usually encrypted. If there are no published keys, the initial contact is generally of the form "I have a security issue that I want to discuss, do you have an encryption key?"

[austinheap]

Is it just me or does RFC 2142 feel like a blast from the past? Do orgs actually check/answer any of these addresses in other people's experience? This RFC hasn't been updated in over 20 years and the Internets were a lot different then. Ya know. Dialup.

[dennypage]

Yes, I think orgs generally monitor security@domain. I manage the security team for a large software company. We have published keys, and read/respond to emails to our security@domain address. I've also used security@domain to establish contact with other security teams.

Many large software companies publish keys for security@domain. Google, Oracle and Salesforce are examples. Some publish secure@domain or psirt@domain keys instead, but I expect that their secururity@domain address is forwarded there and responded to. Microsoft, SAP and Cisco are examples.

[austinheap]

@dennypage I 100% understand that many orgs respond to security@domain (and the ones that don't should!) but personally I doubt it's because of RFC 2142, which defines a whole bunch of mailbox's companies are supposed to answer. It seems the norm is to not answer those mailboxes and the exception is to answer security@domain. An e-mail to webmaster/hostmaster@amazon.com or webmaster/hostmaster@google.com would likely never be seen, for example.

[dennypage]

Yea, I agree that people often ignore webmaster/hostmaster. The value there is just too low. However security@ is commonly manned (as is abuse@). The discussion here boils down to two very important questions, and I'll take the RFC phrasing out of the question statement if that simplifies it for folks:

• What does this proposal address that the already existing security@domain does not?
• Is this proposal intended to supersede security@domain? Or is it just "yet another way" to contact the security team at a domain?

These are questions that need to be addressed in the proposal before it advances.

[austinheap]

If anything they're complementary like @nightwatchcyber pointed out, but I wouldn't even go as far as to call them supplemental.

Is this proposal intended to supersede security@domain?

This proposal has nothing to do with mailboxes like RFC 2142 does. Implementers can choose to accept security alerts via e-mail or not. If someone followed RFC 2142, they should add a Contact: security@domain.com line in their security.txt file, but there is no requirement in this spec for an e-mail to be present in the Contact: directive.

What does this proposal address that the already existing security@domain does not?

The Contact: directive in this spec allows for non-email contacts, like links to bug bounty programs, phone numbers, etc. (Again, this spec isn't about mailboxes.)

[dennypage]

There you go--explanation of rationale and relationship to RFC 2142. Just what the doctor ordered. You need to incorporate this into your proposal.

To be clear, my intent in opening the issue wasn't to debate the merits of your proposal, but to encourage you to incorporate rationale and relationship to RFC 2142, and perhaps other RFCs, into your proposal so that a meaningful discussion can be had with a broader audience.

A thorough examination of the relationship to existing RFCs is a general expectation for any draft proposal wishing to advance.

[nightwatchcyber]

@dennypage @austinheap - I submitted a pull request with language addressing this issue, please take a look

[EdOverflow]

Closing this ticket as resolved (https://github.com/securitytxt/security-txt/pull/52). Thank you everyone. I really appreciate your help.