ICMC17: What's new in TLS 1.3 (and OpenSSL as a result)

Rich Salz, Akami, OpenSSL Developer

TLS 1.0 was a slight modification of the original SSL protocol by Netscape, published in January 1999. Basically the same as SSL3 - it is bad, it is weak, it has no good ciphers and it's still in wide use.

TLS 1.1 came out in April 2006. It would be great to kill both TLS 1.0 and 1.1 off - but it's just too hard.
TLS 1.2 has been around since August 2008. Since then, there's been a bunch of new RFCs and algorithms from all over the world.

TLS 1.3 was approved in October 2015 in IETF.

Background on IETF: If it doesn't happen over email where everyone can see it, it didn't happen.  It is divided into areas like Security, Operations, DNS, etc - each area has area directors and working groups and working group chairs.  Very well laid out process, very egalitarian.

The working groups work by consensus - they demonstrate by humming, so people can't be singled out by raising hands or doing a verbal roll call. Many documents now do their iterations in GitHub.

IETF also has RFC editors who make sure final revisions follow the consistent and correct format for an RFC.

TLS 1.3 had a few goals - encrypt as much of the handshake as possible, reduce the handshake latency - ideally to one or zero roundtrip for repeated handshakes, update record payload and make it more privacy friendly.

Only uses ECDH and DHE (but nobody will use DHE - too expensive). All connections have perfect forward secrecy.  Most things are encrypted (SNI is not). The most common curves will be NIST P-256 or X25519.

There will be improvements to bulk encryption. Three cipher types and two variations: ChaCha220/Poly1305, AESGCM128(256) and AESCCM 128 (256). The cipher lists and choices were just getting too long and mistakes were being made. these are the ones you need.  The cipher suite no longer specifies key exchange or authentication mechanism - they are negotiated now.

The bulk encryption ciphers chose are all modern, secure and AEAD-only - in addition to confidentiality, you also get integrity (authenticity).

Authentication improvements: DSA was removed, RSA was kept and prefers RSA-PSS over PKCS #1.5.

There was general cleanup, like the removal of renegotiation (ie export crypto). Almost every message now has extensions: OCSP or Certificate Transparency stapling on server and client side. There is now padding at the TLS layer (this was slightly controversial). There is only one hash mechanism: HKDF (RFC 5869) and it's used consistently (and correctly). They've done cryptanalysis and attack events, found issues and fixed them. There will be no SHA.  Does that mean SHA3 is no good? No, there were just concerns about performance and newness when TLS 1.3 work started.

SHA will still be around in certificates, though even SHA1 is being rapidly phased out.

Renegotiation is gone. There were many use cases: request client cert, "step-up" crypto algs and re-key. It was buggy and unclean and a source of problems. Only strong crypto is available.

There is allowance for session resumption. It prefers sessions over tickets. Sever can send session information at any time and the session is like PSK. PSK is like session resumption. If you're reconnecting, send data with the resumption :-)  This gets you O-RTT - Zero Round Trip Tickets.

0-RTT: client connects, C&S do the ECDHE dance. Client remembers the server's key share. Next time, client reconnects and sends data encrypted with that key.  This helps to avoid an extra round-trip with less latency.  This makes your web faster and then we can all make more money.

0-RTT has a big butt... there is no PFS with early data. That data can be replayed elsewhere (GEt is idempotent). Nobody was really listening to these concerns until Colm@Amazon spoke and posted two weeks ago. No everybody's trying to figure out what to do. We want to do the right thing, but one of the primary goals was to improve performance - and browser vendors will use it anyways.

TLS 1.3 status is very close to IESG review. Chrome and FF and some others are at Draft-18. Draft 19 had minor changes, Draft 20 is incompatible.

ICMC17: Control Your Cloud: BYOK is Good, But Not Enough

Matt Landrock, CEO, Cryptomathic

BYOK suggests a one-way mechanism: your key, my cloud.

The word "Key" tends to be generally understood in a very broad sense (symmetric and asymmetric),  however in cloud service providers it has a bit of a different definition.

The current key management servifes offered are MS Azure, Amazon AWS and Google Cloud Platform. Azure uses Thales and Amazon uses Gemalto, Google doesn't appear to use an HSM at this time. Their biggest differences are around the BYOK protocols (key wrapping, etc).

BYOK is an important tool, but should not be the only tool in your tool box.  It will help you get your own key into the cloud, so you know it meets your standards for generation. The cloud provider will handle things for you, but not in a consistent way - so lots of hurdles to go through to get this done.

MYOK - Manage Your Own Keys! MYOK implies you can manage import/export, lifecycle and generation all by yourself. Provision when you need them, destroy when you're done.  How can you do this in a way that is meaningful for your business?

Centralized key managers are moving into the market space.

Key management is more than just keys - name, algorithm, length, export settings. And, many key formats end up being very vendor specific (some use standards like PKCS#8, but many more are just proprietary).

ICMC17: TLS Panel Discussion

Tim Hudson - Cryptsoft
Steve Marquess - OpenSSL
David Hook - Bouincy Castle
Kenn White - Open Crypto Audit
Nicko van Someren - Linux Foundation

There are many implementations of TLS, from C and assembly implementations to Java implementations. OpenSSL has many forks - some obvious, some hidden under the covers. More implementations are good, as we don't want to suffer from monoculture.

There is possible value in creating a drop in API that multiple implementations could use. Nicko suggests creating an open process to create that API - it would not necessarily be from an existing implementation. It could possibly allow for more automation. APIs tend to grow out of necessity, and are not always pretty. A common API could help with security and fuzz testing.

There was then a long side discussion on libsodium (NACL), which is only a crypto library at this point as the "N" piece of networking/TLS hasn't been implemented, yet, but there are lots of language bindings out there.

How long does it take to create a new TLS library?  Apparently a new one was created recently in 3 weeks - leveraging someone else's crypto.  Language choice is important.

The older APIs have to consider legacy deployments, for example OpenSSL still supports VAX/VMS.  Another perspective - a new TLS implementation has taken another team 5 months already. When you have a user base you need to support, that seems to add time to the implementation.

There was a question about moving your implementation from TlS 1.0 to TLS 1.3? One of the OpenSSL developers noted that there is a lot of code reuse, but also a lot of #ifdefs. (TLS 1.0 is not, yet, #ifdef''d out of OpenSSL, but probably will be within the year).

There was a question about what is the biggest issue with FIPS validations? The general answer: consistency. That is, OpenSSL helped take multiple validations through at the same time, which was based on the same code and mostly the same documentation took a different amount of time and got completely different feedbacks.

ICMC17: Inside the OpenSSL 1.1 FIPS Module Project

Tim Hudson, CTO Cryptsoft and Mark Minnoch from SafeLogic.

In July 2016, OpenSSL announced the commencement of a fresh attempt to do a FIPS validation of OpenSSL. There are over 244 validated products on the NIST list that obviously use OpenSSL in their validation boundaries and it's included in most (all?) operating systems - it's pervasive!  So, why is it so hard to validate?  It starts out as open source with lots of competitors/stakeholders interested in it.

Unfortunately, stakeholder goals and project goals do not always align. For example, the project wants to support many platforms - stakeholders want to focus on only one or two. The same goes for the number of algorithms supported and validated.

Previously, FIPS140 work was effectively entirely funded for the OpenSSL project from 2009-2014, as there was no long term or major sponsor at this time.  The sponsors funding OpenSSL FIPS all had different goals (other than wanting to sell into the US government), which made it very difficult to manage. This is a hard project, with many people yelling at you with different goals and wasn't very rewarding - can't just expect people to do this for "fun". [note: yes, nothing about FIPS is "fun" - practical, yes, but not fun]

The first validation was very painful for the developers, so OpenSSL knows they have to do it differently if they are ever going to do it again.  OpenSSL started their first FIPS 140-2 validation in June 2002, certificates were not received until March 2006!

There have been a total of 9 unique validations, to keep up with new hardware platforms and implementation guidance changes.

The OpenSSL FIPS 1.0 module based off of the OpenSSL-0.9.x is no longer usable, there is still a bit of life left in OpenSSL FIPS 2.0 module (#1747, #2389, #2437) as it is based off of the OpenSSL-1.0.x code. But, a major update is required for a new OpenSSL FIPS module to work with OpenSSL-1.1.x.   For this go round, goal is to make the FIPS140 related changes "less intrusive".

Current validations cover dozens (hundreds?) of platforms (OS vs hardware).

For the new validation, the only current sponsor is SafeLogic, but additional sponsors are needed to fund OpenSSL FIPS development and FIPS lab testing - resources are available now to begin work. 

This is a high risk validation, many people will be watching the validation which means people are cautious to enter - which creates a longer timeline. Keep in mind that TLS 1.3 is only available in OpenSSL 1.1.x, so if that's important to your customers, consider helping out financially to get this project going.

It's hard to get the sponsors on board, as they all want to see another sponsor already on board and to share the cost, but they still want to wield great influence over the work.

If this project doesn't happen, there are fewer options for FIPS libraries and will require you to do more of your own FIPS work.  Taking multiple versions from different companies through CAVP/CMVP is a waste of their resources as well.  Also, if everyone develops independently, the federal government will end up with inconsistent implementations.

Originally team was going to work on FIPS 140-2 work before TLSv1.3, but swapped the priorities. That was easier to get a sponsor for, as it's well defined project and now the FIPS work can happen with the TLSv1.3 in place.

OpenSSL has refactored algorithm testing approach and want to better support embedded systems, and do better with entropy generation.  Need to pick up extra NIST work and try to take SHA3 through CAVP/CMVP.

Will continue to look at improvements to POST (like defining what it means for software). Also considering add ChaCha/Poly1305.

Currently cannot commit to many requested features, just due to trying to keep a reasonable timeline.  The current schedule estimate from "start" to certificate is 18months, based on their experience taking other modules through.

Please consider sponsoring this project so it can get off of the ground!

ICMC17: Keynote: Driving Security Improvements in Critical Open Source Projects

Nicko van Someren, CTO, Linux Foundation.

Open Source is huge and it's here to stay, with nearly 4 million contributors world wide, 31 billion lines of committed open source, etc - we aren't getting away from it now! Open Source is the "roads and bridges" of the Internet, which runs on Open Source.

Sometimes open source breaks... things like heartbleed, shellshock, Poodle, etc. The Internet runs on opensource, but it's not always properly looked after. Linus's Law: "Given enough eyeballs, all bugs are shallow" - so why are there still bugs? Well, not enough eyeballs!

Open source software is not more or less secure than closed source - but different. Typically there are more diverse group of people working on the source, but serially over a long period of time. There is often a culture of "code is more important than specification" - a cultural difference from most businesses.

Major projects are very under resourced, like OpenSSL - run  by millions of businesses, but only got $2000 in support in 2013.  NTPD is run by every major stock exchange, but some of the code is 35 years old, maintained by one guy, part time.  Same for bash, GnuPG, and OpenSSH.

These open source projects are not  given the resources they deserve.

The Linux Foundation created the Core Infrastructure Initiative. The CII aims to substantially improve security outcomes in the OSS projects that underpin the Internet. The CII funds work in security engineering, security architecture, tooling and training on key OSS projects.

This market is changing quite quickly as well - who would've known 4 years ago how important node.js would be?

CII is a non profit funded by industry partners, like Intel, Microsoft, Google, Hitatchi, Dell, Cisco, Amazon, Bloomberg, Fujitsu, etc.

Open source can do all of the same things commercial enterprise does for building secure software - just harder, because there is no way to give a top-down mandate (ala Bill Gates fixing security mindset at Microsoft).

Groups and individuals must think about security early and often, it cannot be just one squeaky wheel mentioning security. It requires buy-in from the entire community. Fostering this culture of security within your open source project is the single most important thing that you can do to improve your security outcomes.  Security needs to be given equal weight with scalability, performance, usability and other design factors.

CII is trying to find out where the risks and problems are by doing the CII Census Project to discover the really critical open source projects, how responsive the developers are, historic trends for bug and vuln density and how healthy the development community is. Did a snapshot a couple of years ago and created a scorecard. working now on updating it to be a continuous evaluation.

Once critical projects have issues identified, CII is trying to focus their resources on fixing it. Maintenance work is not fun, but it is vital. They are trying to pay developers to work on key projects full time, match willing and able developers to relevant projects and encourage educational establishments to get students involved.

Additionally, working on improving open source security tools. This means funding development of new or improved OSS security tools, make sure they are usable and have a good signal to noise ratio. Problem with some of the existing tools - terrible documentation! So, there is even a need for paying people to write documentation for how to use and deploy continuous security testing.

CII also wants to drive better security process in OSS projects with their CII Badge program - an open process for evaluating security processes in your community. It's a self assessment, with the goal of avoiding security theater, so it only includes items that really improve security.

CII has a travel fund to send developers to security conferences to learn about security and additional funding to get key OSS developer teams to meet face to face to set priorities and collaborate (like OpenSSL).

If your company is building your business on open source software, you should consider funding those projects and CII to help push better security practices, etc.

Oracle: Oracle Open Allies, a PFLAG Panel

A panel discussion with PFLAG members: Formerly Parents, Families, and Friends of Lesbians and Gays

Panelists:

Mitzi Henderson, Past National PFLAG President 

Rosemary Malvey, PFLAG Speaker's Bureau (Parent)

Joyce Miller, Straight Spouse Support Group

Windsor Smith, PFLAG San Jose Vice President

Moderated by Cynthia Chin-Lee, OPEN Ally team lead

The event is hosted by Oracle's OPEN group (Oracle Pride Employee Network), a resource for gay, lesbian, transgender, queer and questioning employees.

Cynthia Chin-Lee published a book about Prop 8 called Operation Marriage five years ago, which was since made into a movie! 

Having allies is important, and Oracle is a big ally for their employees. In some US states, you can still be fired for being a homosexual, in some countries you can be killed.

Mitzi Henderson was distressed when she discovered that her church, and other churches, would not provide pastoral services around gay and lesbian issues, which drove her to get involved with PFLAG.

Joyce Miller is a retired nurse and grief counselor, she is a member of the straight spouse support group. Some people were celebrating their gay and lesbian children, but discovered it wasn't always a shared emotion across both parents, which inspired her to get involved in the straight spouse group.

Rosemary Malvey volunteers for Mission Hospice, 12 step programs, and PLFAG. When her son came out to her, she was full of supportive words, but she was full of trepidition about his health, job prospects and safety.  

Windsor Smith attended the Robert E. Lee high school (home of the rebels), and later came out to all of his family and friends in one fell swoop, and quickly learned about various support groups.

Mitzi recalls a terrible story about a gay man arrested in NYC that was arrested and beaten by police just before the gay pride parade, so his mother marched in the parade with a sign asking parents to support their gay children.  She started a support group in NYC, then reached out to other groups and formed a national organization, PFLAG.  They wanted rules that the groups could not be exclusive - ie only for one religion, only for people with gay sons, etc.  It's important for parents to be proud of their children, no matter what their sexual orientation is.

Mitzi had a chance to go to congress to testify on the national issues facing their children to subcommittees in congress. Other research showed that many states had even more restrictive laws than the federal government., and PLFAG is trying to work on this.

When Joyce's son came out to her, when he had finished college and was living abroad, he was very careful to right away to tell her that it was nothing she had done and that it had nothing to do with her recent divorce from his father.  She was concerned about AIDS, at that time it was an out of control epidemic.  She found a lot of support from the other parents in PFLAG. She had been sending her son packages full of pamphlets about AIDS, but she found out that was not going to help her continue to build her relationship with her son.  Her son is now 55 years old and recently married to his partner of 15 years.

Joyce used to handle the hotline phone line for PFLAG for the Bay Area.  She had been getting calls from people who had discovered their husband or wife was actually gay or lesbian.  The straight spouse goes through very different issues than a parent of a gay or lesbian child.  The straight spouse support group doesn't have many "long timers" as it were, as they get their needed healing, they can move on.

Rosemary Malvey has been a PFLAG member for nearly 20 years - she had never heard of PFLAG until she needed PFLAG.   When her son came out to her, he did it by telling her that he was in love and happier than he's ever been.  She was happy he shared this with her, and was very supportive while she was visiting him.  But, after she left, she cried the entire flight home. She worried about her son suffering for his sexual orientation both socially and in his career.  Fortunately, a friend pointed her to PFLAG and told her "it's no big deal" and to get over it.

Rosemary's daughter didn't realize she was a lesbian until she was 35!  Finally, many pieces of her life have fallen into place, and she was finally happy!

Windsor Smith likes being involved with PFLAG and wants people know that they also welcome gay, lesbian and transgender members - not only parents.

A question from the audience: is there a place for siblings to go for support? Resounding answer: PGLAG! Open to all.

A great question about pronouns if your child comes out as transgender. There are many clever pronouns, like "they" in the singular sense, and many other options (zhe/zer/etc). But, the best way is to ask what pronouns the individual prefers.  Some people, including Windsor, put their preferred pronouns in their email signature.

Another question about differing cultural issues - coming out in a conservative culture (religion, ethnicity, etc). If your parents cannot accept you or come to PFLAG, Rosemary still encourages you to go to PFLAG yourself and find a surrogate accepting parent.

PFLAG is a great place to find allies of all sorts. Many of our loved ones are biased, and it's good to challenge them when you can and know you can find an ally.

For younger folks, most junior highs, high schools and colleges have support groups specifically for youths.

At the end of the day, PFLAG is an excellent resource for parents and anyone with questions. If they aren't the right place, they will likely know the direction to point you.

This event was additionally put on to raise money for Equity Florida, the group that has helped many victims of the Orlando shooting.  If you can, please consider donating.

OASIS PKCS11 TC Published PKCS#11 2.40 Errata 01 and Header Files!

After we released PKCS#11 2.40, the PKCS11 Technical Committee and our public reviewers found some issues. I'm proud of the work the technical committee did with the public to create  Errata documents for PKCS#11 2.40.

These documents, where created, supersede PKCS#11 v2.40. That is,  if there is an updated constant identifier in the Errata, that should be considered correct.  The PKCS#11 2.40 Usage Guide remains the most up to date, and it is a committee note (not a standard).

In addition to the updated errata documents, we are excited to launch our first official set of header files since moving under the OASIS banner (aka "normative computer language definition files"): pkcs11.h, pkcs11f.h, and pkcs11t.h.

The PKCS11 TC has published Approved Errata for PKCS #11 V2.40. See the announcement at https://www.oasis-open.org/news/announcements/pkcs-11-v2-40-approved-erratas-published-by-pkcs-11-tc or use the links below.

• PKCS #11 Cryptographic Token Interface Base Specification Version 2.40 Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/os/pkcs11-base-v2.40-errata01-os.html
• PKCS #11 Cryptographic Token Interface Base Specification Version 2.40 Plus Errata 01
  OASIS Standard Incorporating Approved Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/os/pkcs11-base-v2.40-errata01-os-complete.html
• Normative computer language definition files
  http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/os/include/pkcs11-v2.40/

• PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/errata01/os/pkcs11-curr-v2.40-errata01-os.html
• PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Plus Errata 01
  OASIS Standard Incorporating Approved Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/errata01/os/pkcs11-curr-v2.40-errata01-os-complete.html

• PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 2.40 Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-hist/v2.40/errata01/os/pkcs11-hist-v2.40-errata01-os.html
• PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 2.40 Plus Errata 01
  OASIS Standard Incorporating Approved Errata 01
  http://docs.oasis-open.org/pkcs11/pkcs11-hist/v2.40/errata01/os/pkcs11-hist-v2.40-errata01-os-complete.html