i hate to be late to the party, but.. Is the overall effort here really just framing what the security.txt for all IETF-LLC properties/things should be? (also I had thought jim duncan's security.txt thing was long-since a defacto standard... but: draft-foudil-securitytxt-09 says otherwise, oops) On Thu, Aug 6, 2020 at 11:00 AM Livingood, Jason <Jason_Livingood@xxxxxxxxxxx> wrote: > > I would love to see comment on these 2 key questions: > > (1) > * The proposed mechanism for reporting a vulnerability. > > When I originally thought about this I was concerned at the default to use email, acknowledging that this is something with which most IETF participants are quite comfortable. I wondered if it might be better to specify that a web interface was the reporting method, which would automatically generate a report ID number on submission that a bug reporter could use for their reference later on. In contrast, an email may not arrive or may be delayed and automatically generating an acknowledgement response with a ticket/tracking number would rely on an additional system that may have communications issues with the email system. > > It seems like a web-based reporting system may also provide a better level of security protection by encrypting the channel & contents of the communication vs. less secure email. > I think the easiest thing to use is email, forcing a web interface is rough on some folks :( an email to a ticket system with auto-responder (and ideally both gpg verification inbound and signing outbound) would be nice. that could be published on the eventual security.txt even :) "send gpg signed mail, if you can gpg sign, expect a gpg signed mail from our ticket system with incident-id" > (2) > * What the email address should be for reports to be sent to. > > @Jay - Can you list the options being considered here to help aid the discussion? > security@ ? :) > Thanks > Jason > > >
