[Owasp-leaders] OWASP at the IETF 101 Meeting - Read Out

Sherif Mansour sherif.mansour at owasp.org
Wed Mar 28 18:27:42 UTC 2018


Bcc'd IETF members

Hey everyone,

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
<https://www.owasp.org/images/9/91/OWASPLondon20180125_TLSv1.3_Andy_Brodie.pdf>
).* 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
      <https://github.com/Labs64/swid-generator/>).
      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
      vulnerability.

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

- *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
   watch carefully.

- *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?

      - *Capsule:
   <https://datatracker.ietf.org/meeting/101/materials/slides-101-saag-nadim-kobeissi-capsule-02>
   *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
   Montreal.
   - *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
   highlight
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20180328/8e16df5d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-03-25 at 16.50.36.png
Type: image/png
Size: 294504 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20180328/8e16df5d/attachment-0001.png>


More information about the OWASP-Leaders mailing list