[Owasp-leaders] OWASP at the IETF 101 Meeting - Read Out
sherif.mansour at owasp.org
Wed Mar 28 18:27:42 UTC 2018
Bcc'd IETF members
Last week I have had the pleasure of attending the IETF 101 meeting in
London, and I quite enjoyed it. there was a lot to take in, and a lot OWASP
can help to fill in gaps in the security eco-system. I wrote a small report
on what I found interesting, I hope you enjoy it.
*IETF 101 Highlight - TLS 1.3:*
TLS 1.3 has been approved and now moved for review. If any organization is
using passive proxying they are recommended to move to active proxying post
haste! This is because TLS1.3 cipher suites only include forward Secrecy
ciphers. The review usually takes 6-8 weeks. If there are technical
concerns it can be rejected, but for all intents and purposes expect a roll
out later in the year. Google (and other vendors) already have code in
browsers in preparation for the final draft of the protocol and roll out
later in the year. there is a great paper on TLS 1.3 rm an OWASP London
meeting (It can be found here
).* Note: *As some of you know this year is also the PCI deadline for
removal of older versions of TLS.
To commemorate this moment IETF released some TLS 1.3 stickers!
*Interesting working groups and technologies that caught my eye:*
- *SWID Tags:* <https://en.wikipedia.org/wiki/ISO/IEC_19770> CPEs (Common
Platform Enumeration) is going away*.* Replacing it are SWID Tags, and
they have *three* added improvements over CPEs:
1. *They are linear. *This means for a known vulnerability (CVE) you
are provided *a range *where they software is vulnerable. This
eliminates a lot of guess work, of which versions or sub-versions of a
software is vulnerable and on which platforms etc..
2. *There is both an authoritative (can be externally advertised) and
non authoritative (for internal apps or internal versioning).* This
is great for internally developed apps, and now appsec engineers can
eliminate the guess work on where that version o an app in installed or
which versions are vulnerable, by looking up the SWID tags. There is an
open source maven plugin that generates SWID Tags available (see link
3. *Its being supported by NVD. *New vulnerabilities (where possible)
will have SWID Tags, and historic CVEs also are being updated with SWIDs
(again where possible). the wider the adoption the easier it will be to
accurately identify apps and the versions that are exposed to a specific
- *DOTS:* <https://datatracker.ietf.org/wg/dots/about/> The aim of
DDoS Open Threat Signaling (DOTS) is to develop a standards based approach
for the realtime signaling of DDoS related telemetry andthreat handling
requests and data between elements concerned with DDoSattack detection,
classification, traceback, and mitigation.
- *SACM: <https://datatracker.ietf.org/wg/sacm/about/> *Secure Automation &
Continuous Monitoring(SACM) If you use SCAP for Secure configuration
management*, *this is the natural progression. It expands on a vendor
neutral for configuration checks and is aimed to assess the security of an
asset/endpoint (including network devices & app layer).
- *MILE: <https://datatracker.ietf.org/wg/mile/about/> *Managed Incident
Lightweight Exchange (MILE) supports computer and network security incident
- *QUIC: <https://datatracker.ietf.org/wg/quic/about/> "The next transport
protocol for the internet <https://quicwg.github.io/>"* I have not seen
a more active working group during IETF 101 than QUIC - this is one to
- *Token binding <https://datatracker.ietf.org/group/tokbind/about/>: *Token
Binding enables defense against web based session hijacking (theft of HTTP
cookies, OAuth tokens, etc.) by cryptographically binding security tokens
to a secret held by the client.
- *Using TLS in Applications
<https://datatracker.ietf.org/wg/uta/about/>: *Many application
protocols have defined methods for using TLS to authenticate the server
(and sometimes the client), and to encrypt the connection between the
client and server. However, there is a diversity of definitions and
requirements, and that diversity has caused confusion for application
developers and also has led to lack of interoperability or lack of
deployment. Implementers and deployers are faced with multiple security
issues in real-world usage of TLS, which currently does not preclude
insecure ciphers and modes of operation.
- *Human Rights Protocol Considerations (hrpc):
<https://datatracker.ietf.org/group/hrpc/about/> *The Human Rights
Protocol Considerations Research Group is chartered to research whether
standards and protocols can enable, strengthen or threaten human rights.
- This really interests me. We often delegate technology to do many
important things on our behalf. Should those autonomous systems have some
rights/code when operating on the internet on our behalf. I.e. an
autonomous system appears on the internet.. what should it be
allowed to do
as a "given"?
- And are there protocols that go against/threaten this?
*Open Source & Standardized Encrypted Collaborative Document Editing
(think encrypted Google Docs, there Google can't read the doc). Also... the
speaker is really funny <nadim at symbolic.software>!
For more please check out the other IETF areas, the security *area* can be
found in the following link <https://datatracker.ietf.org/wg/#sec>
*Where can the OWASP community help?*
As we all know, standards are just one part of the overall eco-system. Lots
of guidance, tooling & awareness is required for these technologies. As
OWASP there are a few things we can do:
- *Writing code:* We can participate in hackathons or write our own
tooling adopting new technologies / or help troubleshoot them. please see
the upcoming events, you can participate remotely. The Next one is in
- *Writing Guides: *We can spread the word by writing good best
practices and technical documents on how to leverage new technologies which
help improve security.
- *Spread the word: *Encouraging adoption, inviting IETF members to
speak at OWASP events, writing guest blogs etc..
- *Having a two way dialogue:* As OWASP we can provide feedback
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-03-25 at 16.50.36.png
Size: 294504 bytes
Desc: not available
More information about the OWASP-Leaders