User:Sidstamm/Notes April 2013 NIST CA Workshop

From MozillaWiki
Jump to: navigation, search

Note: these notes are rough and incomplete, but are nuggets of interesting information I wrote down while attending this: http://www.nist.gov/itl/csd/ct/ca_workshop.cfm

Steve Bellovin

  • we put too much trust in cryptography. "encrypted does not mean secure"
  • usability is a very big problem.
  • people don't know what a certificate is (showed screenshots of mossad.gov.il and senate.gov failing cert checks) whose behavior must change?
  • upgrades suck
  • etc...
  • DNSSEC requires a chain of trust (new security critical requirements on CAs)
  • business models ... how do you fund the work for things like CT?

who should vouch for whom?

  • delegation doesn't often work as intended (can organizations run their own structural sub ca?)
  • How do we expect CAs to understand internal structures?

partial answers

  • what schemes give us most benefit during transition?
  • does it need scale to have value (CT)?

who is the enemy?

  • governments? attackers who are very sophisticated?
  • lots of major issues (slide with lots of bullets)

Russ Housley

vigil security, LLC (https://www.ietf.org/iesg/bio/russ-housley.html)

  • PKI mostly working, but too fragile
  • CAs suffer a huge economic asymmetry
    • lots of value for an attacker who can compromise a CA
  • cert status checking is often turned off
    • too many RTT
    • inconsistent browser implementations
    • NEED CONSISTENCY
  • cert subject names
    • CAs are not aligned with DNS (all CAs can issue for all domains)
  • CAs still have certs with obsolete hash algorithms or key types
  • CONCLUSION: use DNSSEC
  • CONCLUSION: issue new certs using only SHA-256 and 4096 public key sizes
  • Deviations from standards make this harder (Web PKI deviates from RFC 5280)

Ryan Koski

  • Covers CRL & OCSP operations
  • and also SCVP (RFC 5055 - not commonly used)
  • CRLS:
    • Con: grow over time (2013, 41MB - at go daddy)
    • Single list of problematic customers
    • No positive "valid" marks
    • more efficient for CAs that rarely revoke
  • OCSP:
    • Small
    • Real-time online status if desired
    • Positive confirmation
    • requires RTT for each cert
    • Adds latency to TLS handshake
    • Load on OCSP service

Criticims:

  • Performance impact on validation checking.
  • Privacy criticism of OCSP
  • Availability criticism (captive portals, egress filtering, random failures)
  • AGL: "It only works when you don't need it"

Stapling

  • helps with:
    • Privacy
    • Captive portals
    • Performance
  • Limited to single OCSP response, need whole chain stapling

Proposal:

  • Must-staple extension

Recommendations:

  • OCSP stapling
  • CAs should avoid delegated OCSP signing
  • Libraries/Toolkits should provide high-level APIs for applications

Q&A

Q: Short lived certificates? Isn't that the same as stapling?

Q: how do we address malicious/compromised CAs? Can't Stapling help detect CAs gone rogue?

Q: one issue with OCSP: Spec mandates SHA-1, we should be able to evolve it

Q: Does stapling work with SSLv3? NO

Emilia Kaspar - Google

Certificate Transparency

  • Minimize window between incident and response
  • Make the computers of the world gossip
  • Only domain owners know which certs are legit for their domain
  • CT will make all public ee TLS certs public knowledge and hold CAs accountable for certs they issue.
  • MUST be compulsory
  • NO side channels in TLS handshake (NO OCSP)
  • NO noticeable performance penalty for page load
  • MUST be backwards compatible
  • To verify logs of issuance, people must "share" their views of the log to make sure nobody is mucking with it in isolated fashions.
  • Valid concerns: Log availability and log acceptance
  • Need multiple logs to detect compromise (and the private key is almost as sensitive as a CA private issuing key.


Richard Barnes

DANE - an overview.

Constraining the PKI

  • Before you get DANE you need DNSSEC


Alexandra Grant

Dartmouth - undergraduate thesis research

"Search for Trust"

  • Survey of proposed attack mitigation techniques (CAA, DANE, Convergence, etc)

Aart Jochem

The DigiNotar crisis

  • Organizations need to manage certificates as assets (and have backups)
  • need an inventory of certificates so you know what you have and where it comes from
  • Wants DNSSEC
  • Wants grace period of two weeks before announced revocation of CA !!


Brad Hill

Locale and CA trust

  • Annotate CAs with regions/locales where they issue.

Tim Polk

OSTP What can we (gov't) do to help build consensus?

Background:

  • it's been a while since diginotar
  • more fraudulent certs have been found
  • not much has changed.

Options breed indecision

  • We probably can't afford to implement all of them.
  • ...Even though they're mostly complementary

Need coordination to solve the problem (or to implement anything, really).

  • Market has to be convinced the security improvement is worth the risk.


This must be driven by the private sector. Requires multistakeholder support.

We need customers that can commit to deployment. (Sites)

Grand Challenge: Establish industry organized cross-sector initiative to select a solution, manage process, and lead deployment

Q: ben wilson; what kind of online community do we develop? Someone needs to call consensus.

Something we need might be satisfied by a non-wg list in IETF or something (includes IPR rules). Maybe an informal group is better, like a google group, or the internet society's list.

Retrieved from "https://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_April_2013_NIST_CA_Workshop&oldid=648643"