← Prev in month ← Prev in thread
Next in thread → Next in month →

[[email protected]: [members] Security Considerations section added to OASIS standards track document templates]

From
Michael S. Tsirkin
Date
2018-06-26T18:42:00+00:00
ID
Thread
[[email protected]: [members] Security Considerations section added to OASIS standards track document templates]
This might be relevant. At least the PLATFORM_IOMMU does affect security. Behaviour around reset might also leak information. If anyone has the cycles, this might be a good thing to add to the spec.

-----

Forwarded message from Chet Ensign <>

-----
Date: Tue, 26 Jun 2018 14:24:11 -0400
From: Chet Ensign <>
To: 
Cc: Ask The TAB List <>
Subject: [members] Security Considerations section added to OASIS standards track document templates
Message-ID: <CAAwgnnPvq0SeF9tf-cx7L9+=>  OASIS members, especially spec editors,   Security is growing to be a top concern in today's decentralized and highly intertwined networked world. Obviously, the work everyone does at OASIS can affect how secure -- or insecure --an implementing system may be.   In light of this and to help encourage explicit documentation of security issues in your work, TC Admin, with the help of the OASIS Technical Advisory Board, has added a new section titled "Security Considerations" to the standards track working draft template.   The section is not required but we strongly recommend giving the subject serious thought before dismissing it! While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. IETF RFC3552 [1], for example,  lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered in their works.   Also, depending on your downstream plans for your work, you may find this content required. For example, you will need to address it explicitly if you apply for IANA media-type registration.    Note also that this is a starting point. We expect that guidance in this area will evolve over the next year or so.   You don't need to wait for your next work product to take this up. We encourage TC members to review IETF RFC3552 "Guidelines for Writing RFC Text on Security Considerations" and consider how it may apply to the work you have underway now.   Please let us know if you have any questions Feel free to contact me or send email to .   Our thanks to Bret Jordan of Symantec for the suggestion.    /chet

----------------

Looking forward to Borderless Cyber 2018, 3-5 Oct, Washington, D.C. Organized by The World Bank, OASIS, and Georgetown University  Chet Ensign Chief Technical Community Steward OASIS: Advancing open standards for the information society  http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393

-----

End forwarded message

-----
← Prev in month ← Prev in thread
Next in thread → Next in month →