<div><div dir="auto">FYI, this is an interesting write up.¬†</div><br><div class="gmail_quote"><div>---------- Forwarded message ---------<br>From: Sherif Mansour <<a href="mailto:sherif.mansour@owasp.org">sherif.mansour@owasp.org</a>><br>Date: Wed, Mar 28, 2018 at 8:29 PM<br>Subject: Re: [Owasp-leaders] OWASP at the IETF 101 Meeting - Read Out<br>To: Owasp leaders <<a href="mailto:owasp-leaders@lists.owasp.org">owasp-leaders@lists.owasp.org</a>><br></div><br><br><div><div><div><div><span style="font-family:monospace,monospace">Bcc'd IETF members</span><br><br>Hey everyone,<br><br></div><div>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.<br></div><div><br></div><b>IETF 101 Highlight - TLS 1.3:<br></b></div><div>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 (<a href="https://www.owasp.org/images/9/91/OWASPLondon20180125_TLSv1.3_Andy_Brodie.pdf" target="_blank">It can be found here</a>).<b> Note: </b>As some of you know this year is also the PCI deadline for removal of older versions of TLS. <b><br><br></b></div><div>To commemorate this moment IETF released some TLS 1.3 stickers!<br></div><div><b></b></div><div><b><img src="cid:ii_jf6zdcdm2_1625ddb1f4dfc307" class="m_4511680139623129442gmail-CToWUd m_4511680139623129442gmail-a6T" style="width:766px;max-width:100%"><br></b><br></div><b>Interesting working groups and technologies that caught my eye:<br></b><ul><li><a href="https://en.wikipedia.org/wiki/ISO/IEC_19770" target="_blank"><b>SWID Tags:</b></a> CPEs<b> </b>(Common Platform Enumeration) is going away<b>.</b> Replacing it are SWID Tags, and they have <u><b>three</b></u> added improvements over CPEs:</li><ol><li><b>They are linear. </b>This means for a known vulnerability (CVE) you are provided <b>a range </b>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..</li><li><b>There is both an authoritative (can be externally advertised) and non authoritative (for internal apps or internal versioning).</b>
 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 (<a href="https://github.com/Labs64/swid-generator/" target="_blank">see link</a>).<br></li><li><b>Its being supported by NVD. </b>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.<br><br></li></ol><li><a href="https://datatracker.ietf.org/wg/dots/about/" target="_blank"><b>DOTS:</b></a>
 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.<b><br><br></b></li><li><b><a href="https://datatracker.ietf.org/wg/sacm/about/" target="_blank">SACM:</a> </b>Secure Automation & Continuous Monitoring(SACM) If you use SCAP for Secure configuration management<b>, </b>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).<br><b><br></b></li><li><b><a href="https://datatracker.ietf.org/wg/mile/about/" target="_blank">MILE:</a> </b>Managed Incident Lightweight Exchange (MILE) supports computer and network security incident management. <br><b><br></b></li><li><b><a href="https://datatracker.ietf.org/wg/quic/about/" target="_blank">QUIC:</a> "<a href="https://quicwg.github.io/" target="_blank">The next transport protocol for the internet</a>"</b> I have not seen a more active working group during IETF 101 than QUIC - this is one to watch carefully.<b><br><br></b></li><li><b><a href="https://datatracker.ietf.org/group/tokbind/about/" target="_blank">Token binding</a>: </b>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.<br><br></li><li><b><a href="https://datatracker.ietf.org/wg/uta/about/" target="_blank">Using TLS in Applications</a>: </b>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.<b><br><br></b></li><li><b><a href="https://datatracker.ietf.org/group/hrpc/about/" target="_blank">Human Rights Protocol Considerations (hrpc):</a> </b>The
 Human Rights Protocol Considerations Research Group is chartered to 
research whether standards and protocols can enable, strengthen or 
threaten human rights.</li><ul><li>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"?</li><li>And are there protocols that go against/threaten this?<br><br></li></ul><li><b><a href="https://datatracker.ietf.org/meeting/101/materials/slides-101-saag-nadim-kobeissi-capsule-02" target="_blank">Capsule:</a> </b>Open
 Source & Standardized Encrypted Collaborative Document Editing 
(think encrypted Google Docs, there Google can't read the doc). Also... <a href="mailto:nadim@symbolic.software" target="_blank">the speaker is really funny</a>!<br></li></ul>For more please check out the other IETF areas, the security <b>area</b> can be found in the <a href="https://datatracker.ietf.org/wg/#sec" target="_blank">following link</a><b><br></b></div><div><b><br></b></div><b>Where can the OWASP community help?</b><br>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:<br><ul><li><b>Writing code:</b>
 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.<br></li><li><b>Writing Guides: </b>We
 can spread the word by writing good best practices and technical 
documents on how to leverage new technologies which help improve 
security.</li><li><b>Spread the word: </b>Encouraging adoption, inviting IETF members to speak at OWASP events, writing guest blogs etc..</li><li><b>Having a two way dialogue:</b> As OWASP we can provide feedback highlight¬†</li></ul><br></div>
_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
</div></div>