TLS 1.3 @ 33c3

The ins and outs of the new big revision of TLS, from the perspective of who deployed it.

https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great_the_good_and_the_bad

1. TLS 1.3 Nick Sullivan Filippo Valsorda @grittygrease @FiloSottile
3. 1994 — SSLv2 1995 — SSLv3 1999 — TLS 1.0 2006 — TLS 1.1 2008 — TLS 1.2 … 3
7. 7 Client Hello Supported cipher suites Client Server Server Hello Chosen cipher suite Key share Certificate & signature Key share Finished Finished HTTP GET HTTP Answer TLS 1.2 ECDHE
8. TLS 1.2 ECDHE 8
9. TLS 1.0, 1.1 and 1.2 are not that different TLS 1.3 is a BIG jump 9
10. RTT--; 10
11. 11 Client Hello Supported AEAD / groups / signatures Key share Server Hello Chosen AEAD Key share Finished Certificate & signature Finished HTTP GET HTTP Answer TLS 1.3 Client Server
12. TLS 1.3 12
13. 13 Client Hello Supported AEAD / groups / signatures Key share Hello Retry Request Chosen group Cookie Hello Retry Request Client Server Client Hello Cookie Other key share Server Hello Chosen AEAD Key share Certificate & signature Finished …
14. Resumption “Hey, I know you!” 14
15. 15 Client Hello Supported cipher suites Client Server Server Hello Session ID Key share Finished Finished HTTP GET HTTP Answer TLS 1.2 ECDHE New Session Ticket
16. 16 Client Hello Session ID / Ticket Server Hello Finished Finished HTTP GET HTTP Answer TLS 1.2 Resumption Client Server
17. 17 Client Hello Session Ticket (PSK) Server Hello Finished TLS 1.3 Resumption Client Server Finished HTTP GET HTTP Answer
18. 18 Client Hello Session Ticket (PSK) Forward Secrecy Client Server Decrypt this with the session ticket key Server Hello Finished Finished HTTP GET HTTP Answer
19. 19 Client Hello Session Ticket (PSK) Key share PSK-ECDHE Client Server Finished HTTP GET HTTP Answer Server Hello Key share Finished
20. 0-RTT! 20
21. 21 Client Hello Session Ticket (PSK) Key share Server Hello Key share Finished HTTP GET HTTP Answer 0-RTT Client Server Finished
22. 0-RTT! But… 22
23. 0-RTT 23 No PSK-ECDHE
24. 24 Client Hello Session Ticket (PSK) Key share Server Hello Key share Finished HTTP GET HTTP Answer Client Server Finished Forward secret from here 0-RTT w/ ECDHE
25. TLS 1.2 is forward secret: • Relatively to the certificate: always (using ECDHE) • Relatively to the ticket key: never 25 TLS 1.3 is forward secret: • Relatively to the certificate: always • Relatively to the ticket key: except 0-RTT early data (w/ PSK-ECDHE)
26. 0-RTT 26 Replays
27. 27 Client Hello Session Ticket (PSK) Key share HTTP GET 0-RTT replay Client Hello Session Ticket (PSK) Key share HTTP GET
28. obfuscated_ticket_age • The client sends the age in milliseconds of the ticket • The server checks it matches its view, with some leeway • Obfuscated with a ticket_age_add value sent as part of the New Session Ticket message struct { opaque identity<1..2^16-1>; uint32 obfuscated_ticket_age; } PskIdentity; 28
29. 29 0-RTT confirmation Client Hello Session Ticket (PSK) Key share Server Hello Key share Finished HTTP POST Finished HTTP POST HTTP Answer
30. max_early_data_size • The server must either accept or reject the early data, entirely, without knowing how much there will be • If it accepts it and can’t process it, it must buffer it • Once the Finished comes, all early data is confirmed • max_early_data_size limits the buffer size • Devised with Drew Springall 30
31. It’s the application’s responsibility 31 Protocols MUST NOT use 0-RTT data without a profile that defines its use.
32. It’s the API’s responsibility 32 • Default to 1-RTT • Allow the server to reject / wait for the Finished • Let the client to decide what to send in the early data
33. HTTP and 0-RTT 33 • Utopia: GET is idempotent! • Reality: nope. GET /send_money.php?to=filippo&amount=1000
34. HTTP and 0-RTT 34 • Utopia: GET is idempotent! • Reality: nope.
35. HTTP and 0-RTT 35
36. 36 Complexity Benefit
37. No Forward Secrecy 37 Client Hello Supported cipher suites Server Hello Chosen cipher suite Certificate encrypted with Certificate Public Key Finished Finished TLS 1.2 Static RSA mode
38. To: IETF TLS 1.3 Working Group Members My name is Andrew Kennedy and I work at BITS, the technology policy division of the Financial Services Roundtable (http://www.fsroundtable.org/bits). My organization represents approximately 100 of the top 150 US-based financial services companies including banks, insurance, consumer finance, and asset management firms. [...] Deprecation of the RSA key exchange in TLS 1.3 will cause significant problems for financial institutions, almost all of whom are running TLS internally and have significant, security-critical investments in out-of-band TLS decryption. [...] 38
39. 39 Out-of-band TLS decryption? Yes, please!
40. Hi Andrew, My view concerning your request: no. Rationale: We're trying to build a more secure internet. Meta-level comment: You're a bit late to the party. We're metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans. More exactly, we are at draft 15 and RSA key transport disappeared from the spec about a dozen drafts ago. I know the banking industry is usually a bit slow off the mark, but this takes the biscuit. Cheers, Kenny 40
43. RC4
44. 3DES
45. MD5 & SHA1 SLOTH 2016
46. AES-CBC Vaudenay 2002 Boneh/Brumley 2003 BEAST 2011 Lucky13 2013 POODLE 2014 Lucky Microseconds 2015
47. RSA-PKCS1-1.5 Bleichenbacher 1998(!!) Jager 2015 DROWN 2016
48. Compression CRIME 2012
49. Renegotiation Marsh Ray Attack 2009 Renegotiation DoS 2011 Triple Handshake 2014 Replaced with lightweight key update
50. Lucky 13 RC4 Weakness POODLE Vaudenay Padding Oracle BEAST CRIME BREACH WeakDH FREAK SLOTH Lucky Microseconds DROWN LogJam
51. 51 & Fortify
53. TLS 1.2 Certificate Authentication • Cipher negotiation protected by Finished Message (MAC) • MAC algorithm determined by cipher negotiation • FREAK, LogJam, CurveSwap: choose weak parameters 53
54. 54 Client Hello Supported cipher suites Client Server Server Hello Chosen cipher suite Key share Certificate & signature Key share Finished Finished HTTP GET HTTP Answer TLS 1.2 ECDHE NOT SIGNED
55. 55 Client Hello Supported AEAD / groups / signatures Key share Server Hello Chosen AEAD Key share Finished Certificate Signature Finished HTTP GET HTTP Answer TLS 1.3 Client Server }
56. Fewer, better choices • Key Exchange, Cipher, Authentication negotiated separately • No arbitrary DH groups • No arbitrary curves 56
60. Safer Resumption TLS 1.2 tickets • Current session keys encrypted with session ticket key • Session ticket key compromise a risk for all connections TLS 1.3 tickets • Next session keys encrypted with session ticket key • Session ticket key compromise only risk for resumed connections 60
61. 61 Client Hello Supported cipher suites Client Server Server Hello Session ID Key share Finished Finished HTTP GET HTTP Answer TLS 1.2 ECDHE New Session Ticket Unencrypted
62. Formal Verification • Tamarin (Oxford, Royal Holloway) • ProScript-TLS, miTLS (INRIA) • nqsb-TLS (Cambridge) 62
63. Standards The IETF way 63
65. Timeline • First Draft: April 17, 2014 • 3Shake, POODLE, FREAK, LogJam, DROWN, Lucky Microseconds, SLOTH, more… • Draft 18: October 26, 2016 • Final draft: February, 2017 (we hope) • TLS 1.2: 79 pages • TLS 1.3: 81 pages (minus references and appendices) 65
66. 66 Github + Mailing List
67. Key Schedule • Inspired by QUIC crypto • Semi-static DH key shared out of band • Tree-based key schedule 67
68. 0 | v PSK -> HKDF-Extract | +-----> Derive-Secret() = early_traffic_secret | v (EC)DHE -> HKDF-Extract | +-----> Derive-Secret() = handshake_traffic_secret | v 0 -> HKDF-Extract | +-----> Derive-Secret() = traffic_secret_0 | +-----> Derive-Secret() = resumption_master_secret
69. What's in a name? Is it TLS 1.3, TLS 2, TLS 2.0, TLS 4, TLS 7, TLS 2017? 69
71. Version Intolerance • Wire versions • SSL 3.0: 3.0 • TLS 1.0: 3.1 • TLS 1.1: 3.2 • TLS 1.2: 3.3 • TLS 1.3: 3.4 ??? • Servers are intolerant of 3.4 • >2% of servers fail connection • Solution: “3.3” in ClientHello,
 real versions in extension • GREASE by David Benjamin 71
72. Version Intolerance 72
73. Implementation Getting our hands dirty 73
74. IETF 95 Hackathon - April 2016 • NSS (C): Martin Thomson and Eric Rescorla • Mint (Go): Richard Barnes and Nick Sullivan Result: Firefox was able to load https://tls13.cloudflare.com! 74
75. 75 • Based on Go crypto/tls • Server only • Audited
76. https://go-review.googlesource.com/q/branch:+dev.tls 76
77. Deploying is hard 77 • First deployed Tris: draft 13 • Supported multiple drafts at a time (“hybrids”) • Browsers sometimes… diverged
79. You may already be using it • Firefox Nightly • Chrome Beta (50%) / Canary 79
80. 80 Chrome Field Test Firefox Nightly Cloudflare Launch
81. Nick Sullivan Filippo Valsorda @grittygrease @FiloSottile https://tlswg.github.io/tls13-spec/ https://github.com/cloudflare/tls-tris https://blog.cloudflare.com/tag/tls-1-3/
82. Y U NO ENCRYPT SNI!? 82
83. 83 Client Hello SNI Key share Server Hello Key share Certificate & signature Finished TLS 1.3 can’t encrypt SNI No key negotiated yet Already has to pick certificate