tls 1 - stanford universityweb.stanford.edu/class/ee380/abstracts/151118-slides.pdf ·...
TRANSCRIPT
![Page 2: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/2.jpg)
Overview
• Background/Review of TLS
• Some problems with TLS 1.2
• Objectives for TLS 1.3
• What does TLS 1.3 look like?
• Open issues/schedule/etc.
TLS 1.3 2
![Page 3: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/3.jpg)
What is Transport Layer Security?
• Probably the Internet’s most important security protocol
• Designed over 20 years ago by Netscape for Web transactions
– Back then, called Secure Sockets Layer
• But used for just about everything you can think of
– HTTP
– SSL-VPNs
– Voice/video
– IoT
• Maintained by the Internet Engineering Task Force
– We’re now at version 1.2
TLS 1.3 3
![Page 4: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/4.jpg)
A Secure Channel
• Client connects to a known server (e.g., it has the domain name)
• Server is (almost) always authenticated by TLS
• Client may or may not be authenticated by TLS
– Often authenticated by the application, e.g., with a password
• After setup, data is encrypted and authenticated
– Though what “authenticated” means to the server is fuzzy
TLS 1.3 4
![Page 5: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/5.jpg)
TLS Structure
• Handshake protocol
– Establish shared keys (typically using public key cryptography)
– Negotiate algorithms, modes, parameters
– Authenticate one or both sides
• Record protocol
– Carry individual messages
– Protected under symmetric keys
• This is a common design (SSH, IPsec, etc.)
TLS 1.3 5
![Page 6: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/6.jpg)
TLS 1.2: RSA Handshake Skeleton
Client Server
ClientHello [Random] //ServerHello [Random], Certificateoo
E(Ks, Master Secret), Finished=MAC(MS, Handshake) //Finished=MAC(MS, Handshake)oo
oo Application data //
TLS 1.3 6
![Page 7: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/7.jpg)
More on Negotiation
• ClientHello contains more than just random values
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
TLS 1.3 7
![Page 8: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/8.jpg)
Client Offers, Server Chooses
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
TLS 1.3 8
![Page 9: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/9.jpg)
What’s in a Cipher Suite?
• Key Exchange (RSA, DHE, ECDHE, PSK, ...)
• Authentication (RSA, DSS, ECDSA, ...)
• Encryption (AES, Camellia, ...)
• MAC (MD5, SHA1, SHA256, ...)
TLS 1.3 9
![Page 10: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/10.jpg)
TLS 1.2: Renegotiation
Client Server
ClientHello [Random] //ServerHello [Random], CertificateooE(Ks, Master Secret), Finished //
Finishedoo
ClientHello [Random] //ServerHello [Random], CertificateooE(Ks, Master Secret), Finished //
Finishedoo
oo Application data //
TLS 1.3 10
![Page 11: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/11.jpg)
Renegotiation Attack [RRDO10]
Client Attacker Server
ClientHello [Random] //ServerHello [Random], CertificateooE(Ks, Master Secret), Finished //
Finishedoo
oo POST /... //ClientHello [Random] // ClientHello [Random] //
ServerHello [Random], Certificateoo ServerHello [Random], CertificateooE(Ks, Master Secret), Finished // E(Ks, Master Secret), Finished //
Finishedoo Finishedoo
oo POST /... Cookie=... //
TLS 1.3 11
![Page 12: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/12.jpg)
Why is this bad?
• Attacker gets to splice their data to the client’s
• Example
– Attacker-controlled request +
– Client’s credentials
• This looks like a renegotiation to server
TLS 1.3 12
![Page 13: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/13.jpg)
Renegotiation Info Extension [RFC5746]
• New extension in {Client,Server}Hello
– Client’s version contains its last Finished on this connection
– Server’s version contains last pair of Finished from this
connection
• If you’re not renegotiating with the same person you get a
mismatch
TLS 1.3 13
![Page 14: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/14.jpg)
Uses for renegotiation (or, why can’t we just get rid
of it...)
• Conceal the client’s certificate
• Post-handshake client authentication
• Refresh the traffic keying material
TLS 1.3 14
![Page 15: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/15.jpg)
TLS 1.2: Renegotiation for Client Authentication
ClientHello [Random] //ServerHello [Random], Certificate, Sign(Ks, gs, ...)oo
gc, Finished //
Finishedoo
GET /secure... //
HelloRequestooClientHello [Random] //
ServerHello [Random], Certificate, CertificateRequest, Sign(Ks, gs, ...)oogc, Certificate, Sign(Kc, ...), Finished //
Finishedoo
oo Response
TLS 1.3 15
![Page 16: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/16.jpg)
Session Resumption
• “Public key” operations are comparatively expensive
– They used to be really expensive
• Solution: amortize this operation across multiple connections
TLS 1.3 16
![Page 17: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/17.jpg)
Session Establishment
Client Server
ClientHello [Random, SessionID] //ServerHello [Random, SessionID], Certificateoo
E(Ks, Master Secret), Finished //
Finishedoo
oo Application data //
TLS 1.3 17
![Page 18: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/18.jpg)
Session Resumption
Client Server
ClientHello [Random, SessionID] //ServerHello [Random, SessionID], Finishedoo
Finished //
oo Application data //
• No new public key operations
• Reuse MS from last handshake
TLS 1.3 18
![Page 19: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/19.jpg)
Triple Handshake (I)
Client Attacker Server
ClientHello [Random] //ClientHello [Random] //
ServerHello [Random], CertificateooServerHello [Random], CertificateooE(Ka, Master Secret), Finished //
E(Ks, Master Secret), Finished //
Finishedoo
Finishedoo
• These connections have the same Master Secret
• “Unknown key share” attack
TLS 1.3 19
![Page 20: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/20.jpg)
Triple Handshake (II)Client Attacker Server
ClientHello [Random, SessionID] //ServerHello [Random, SessionID], Finishedoo
Finished //
GET /secure-resource //
HelloRequestooClientHello [Random] //
ServerHello [Random], CertificateRequest, CertificateooE(Ks, Master Secret), Certificate, Sign(Kc, ...), Finished //
MAC(MS, Handshake)oo
oo Response
TLS 1.3 20
![Page 21: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/21.jpg)
What’s the impact?
• Resurrection of renegotiation attack
• Attacker controls the request
• Client authenticates it
• Thinks he’s authenticating to the attacker
• ... but he’s authenticating to the server
TLS 1.3 21
![Page 22: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/22.jpg)
Fixing the Triple Handshake (Session Hash)
• The problem is the unknown key share on the first handshake
• Fix is to hash the server certificate into the master secret
• Resumed handshakes inherit this context
TLS 1.3 22
![Page 23: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/23.jpg)
TLS 1.3 Objectives
• Clean up: Remove unused or unsafe features
• Security: Improve security by using modern security analysis
techniques
• Privacy: Encrypt more of the protocol
• Performance: Our target is a 1-RTT handshake for naive clients;
0-RTT handshake for repeat connections
• Continuity: Maintain existing important use cases
TLS 1.3 23
![Page 24: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/24.jpg)
Removed Features
• Static RSA
• Custom (EC)DHE groups
• Compression
• Renegotiation∗
• Non-AEAD ciphers
• Simplified resumption
∗Special accommodation for inline client authentication
TLS 1.3 24
![Page 25: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/25.jpg)
Removed Feature: Static RSA Key Exchange
• Most SSL servers prefer non-PFS cipher suites [SSL14]
(specifically static RSA)
• Obviously suboptimal performance characteristics
• No PFS
• Gone in TLS 1.3
• Important: you can still use RSA certificates
– But with ECDHE or DHE
– Using ECDHE minimizes performance hit
TLS 1.3 25
![Page 26: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/26.jpg)
Removed Feature: Compression
• Recently published vulnerabilities [DR12]
• Nobody really knows how to use compression safely and generically
– Sidenote: HTTP2 uses very limited context-specific
compression [PR14]
• TLS 1.3 bans compression entirely
– TLS 1.3 clients MUST NOT offer any compression
– TLS 1.3 servers MUST fail if compression is offered
TLS 1.3 26
![Page 27: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/27.jpg)
Removed Feature: Non-AEAD Ciphers
• Symmetric ciphers have been under a lot of stress (thanks, Kenny
and friends)
– RC4 [ABP+13]
– AES-CBC [AP13] in MAC-then-Encrypt mode
• TLS 1.3 bans all non-AEAD ciphers
– Current AEAD ciphers for TLS: AES-GCM, AES-CCM,
ARIA-GCM, Camellia-GCM, ChaCha/Poly (coming soon)
TLS 1.3 27
![Page 28: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/28.jpg)
Removed Feature: Custom (EC)DHE groups
• Previous versions of TLS allowed the server to specify their own
DHE group
– The only way things worked for finite field DHE
– (Almost unused) option for ECDHE
• This isn’t optimal
– Servers didn’t know what size FF group client would accept
– Hard for client to validate group [BLF+14]
• TLS 1.3 only uses predefined groups
– Existing RFC 4492 [BWBG+06] EC groups (+ whatever CFRG
comes up with)∗
– New FF groups defined in [Gil14]∗Bonus: removed point format negotiation too
TLS 1.3 28
![Page 29: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/29.jpg)
Optimizing Through Optimism
• TLS 1.2 assumed that the client knew nothing
– First round trip mostly consumed by learning server capabilities
• TLS 1.3 narrows the range of options
– Only (EC)DHE
– Limited number of groups
• Client can make a good guess at server’s capabilities
– Pick its favorite groups and send a DH share
TLS 1.3 29
![Page 30: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/30.jpg)
TLS 1.3 1-RTT Handshake Skeleton
Client Server
ClientHello [Random, gc] //
ServerHello [Random, gs]
Certificate, Sign(Ks, Handshake), Finishedoo
Application dataoo
Finished //
oo Application data //
• Server can write on its first flight
• Client can write on second flight
• Keys derived from handshake transcript through server MAC
• Server certificate is encrypted
– Only secure against passive attackers
TLS 1.3 30
![Page 31: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/31.jpg)
TLS 1.3 1-RTT Handshake w/ Client Authentication
Skeleton
Client Server
ClientHello [Random, gc] //
ServerHello [Random, gs]
CertificateRequest, Certificate, Sign(Ks, Handshake), Finishedoo
Application dataoo
Certificate, Sign(Kc, Handshake), Finished //
oo Application data //
• Client certificate is encrypted
• Secure against an active attacker
• Effectively SIGMA [Kra03]
TLS 1.3 31
![Page 32: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/32.jpg)
What happens if the client is wrong?
• Client sends some set of groups (P-256)
• Server wants another group (P-384)
Client Server
ClientHello [Random, DH(P256)] //
HelloRetryRequest [P384]oo
ClientHello [Random, DH(P256), DH(P384)] //...
• This shouldn’t happen often because there are a small number of groups
– Client should memorize server’s preferences
TLS 1.3 32
![Page 33: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/33.jpg)
0-RTT Handshake
• Basic observation: client can cache server’s parameters [Lan10]
– Then send application data on its first flight
• Server has to prime the client with its configuration in a previous
handshake
TLS 1.3 33
![Page 34: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/34.jpg)
TLS 1.3 0-RTT Handshake Skeleton
Client Server
ClientHello [Random, gc, server configuration=XXX]
Application data//
ServerHello [Random, gs]
Certificate, Sign(Ks, Handshake), Finishedoo
Application dataoo
Finished //
oo Application data //
TLS 1.3 34
![Page 35: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/35.jpg)
Anti-Replay
• TLS anti-replay is based on each side providing random value
– Mixed into the keying material
• Not compatible with 0-RTT
– Client has anti-replay (since they speak first)
– Server’s random isn’t incorporated into client’s first flight
TLS 1.3 35
![Page 36: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/36.jpg)
Anti-Replay (borrowed from Snap Start)
• Server needs to keep a list of client nonces
• Indexed by a server-provided context token
• Client provides a timestamp so server can maintain an anti-replay
window
TLS 1.3 36
![Page 37: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/37.jpg)
This doesn’t work (thanks to DKG)Client Attacker Server
ClientHello //POST /buy-something //
ClientHello //POST /buy-something //
[Process purchase]ServerHello [accept 0-RTT], ...oo
[Force server reboot]
ClientHello //POST /buy-something //
ServerHello [reject 0-RTT], ...ooFinished //
POST /buy-something (re-transmit) //
[Process purchase]
TLS 1.3 37
![Page 38: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/38.jpg)
Oops...
• The real problem is multiple data centers
• This is a distributed state problem
– It’s broken in QUIC and Snap Start too
• Resolution: dont even try
– Only use 0-RTT client data for idempotent requests (GETs)
– Difficult application integration issue
– But too big a win not to do
• This can’t be on by default
– And it will need a special API
TLS 1.3 38
![Page 39: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/39.jpg)
Pre-Shared Keys and Resumption
• TLS 1.2 already supported a Pre-Shared Key (PSK) mode
– Used for IoT-type applications
• Two major modes
– Pure PSK
– PSK + (EC)DHE
• TLS 1.3 merges PSK and resumption
– Server provides a key label
– ... bound to a key derived from the handshake
– Label can be a “ticket” (encryption of the key)
TLS 1.3 39
![Page 40: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/40.jpg)
ClientHello
+ ClientKeyShare
^ + EarlyDataIndication
O-RTT | (Certificate*)
mode | (CertificateVerify*
v (Finished) // Note: new message.
(Application Data*) -------->
ServerHello
ServerKeyShare*
{EncryptedExtensions}
{CertificateRequest*}
{ServerConfiguration*}
{Certificate*} ^
{CertificateVerify*} | Server Auth.
<-------- {Finished} v
1-RTT ^ {Certificate*}
Client | {CertificateVerify*}
Auth | {Finished} -------->
v [Application Data] <-------> [Application Data]
<-------- [CertificateRequest] ^
[Certificate] | Post-HS
[CertificateVerify] | Auth.
[Finished] --------> v
TLS 1.3 40
![Page 41: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/41.jpg)
Single Key Derivation and Authentication Logic
• Based on ideas from OPTLS (Krawczyk and Wee)
Key Exchange Static Secret (SS) Ephemeral Secret (ES)
------------ ------------------ ---------------------
(EC)DHE Client ephemeral Client ephemeral
(full handshake) w/ server ephemeral w/ server ephemeral
(EC)DHE Client ephemeral Client ephemeral
(w/ 0-RTT) w/ server static w/ server ephemeral
PSK Pre-Shared Key Pre-shared key
PSK + (EC)DHE Pre-Shared Key Client ephemeral
w/ server ephemeral
TLS 1.3 41
![Page 42: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/42.jpg)
Key Derivation
EphemeralSecret
StaticSecret
mES mSS
MasterSecret
FinishedSecrets
EarlyTrafficKeys
HandshakeTraffic Keys
ExporterSecret
ResumptionSecret
ApplicationTrafficKeys
xES xSS
TLS 1.3 42
![Page 43: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/43.jpg)
Post-Handshake Client Auth
• We removed renegotiation
– But that doesn’t remove the need for post-handshake
authentication
• Current plan: server can send CertificateRequest at any time
– Client responds with “authentication block”
∗ Certificate
∗ Signature over the handshake through server’s MAC
∗ MAC over handshake + Certificate + Signature
• This piece is still under development
– https://github.com/tlswg/tls13-spec/pull/316
TLS 1.3 43
![Page 44: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/44.jpg)
Interactions
• What happens when you combine PSK and post-handshake client
auth?
• This is something you want to work
– Idea is to add client authentication to “resumed” sessions
– In TLS 1.2, this is done with renegotiation
TLS 1.3 44
![Page 45: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/45.jpg)
Attack on Naive Design: Setup [CHvdMS]
Client Attacker Server
oo Handshake //
oo Handshake //
Session Ticket=XXXoo
Session Ticket=XXXoo
TLS 1.3 45
![Page 46: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/46.jpg)
Attack on Naive Design: Reconnect
Client Attacker Server
ClientHello [Random, PSK=XXX] //ClientHello [Random, PSK=XXX] //
ServerHello [PSK=XXX]
Finishedoo
ServerHello [PSK=XXX]
Finishedoo
CertificateRequestooCertificateRequestoo
Cert, Sign(Kc, Handshake), ... // Cert, Sign(Kc, Handshake), ... //
TLS 1.3 46
![Page 47: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/47.jpg)
Analysis
• The question is exactly what you sign
• In draft-10, client signed the server cert but not the server MAC
– Didn’t include client auth with PSK
– ... or post-handshake
• PR#316 includes server’s cert and MAC
– Which transitively includes the server’s certificate
– This reinforces this decision
• This result comes directly from formal analysis with Tamarin
– This is good news!
– Big thanks to Cas Cremers, Marko Horvat, Thyla van der
Merwe, Sam Scott
TLS 1.3 47
![Page 48: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/48.jpg)
Traffic Analysis Defenses
• TLS 1.2 is very susceptible to traffic analysis
– Content “type” in the clear
– Packet length has minimal padding
∗ 0-255 bytes in block cipher modes
∗ No padding in stream and AEAD modes
• TLS 1.3 changes
– Content type is encrypted
– Arbitrary amounts of padding allowed
– ... but it’s the application’s job to set padding policy
TLS 1.3 48
![Page 49: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/49.jpg)
Packet Format
PayloadLengthVersionType
TLS 1.2 Packet Layout
PayloadLengthVersion(Fixed)23
TLS 1.3 Packet Layout
Type Pad(0s)
TLS 1.3 49
![Page 50: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/50.jpg)
Server Name Indication
• How do you have multiple domains on the same server?
• Problem: Each domain may have its own certificate
– How does the server know which one to present?
• Wrong way: each server gets their own IP address
– Obvously this does not scale
– But it’s what people actually do (thanks Windows XP and
Android 2.2)
• Right: ClientHello extension indicating server domain name
– “Server Name Indication” (SNI)
• SNI is required for TLS 1.3
TLS 1.3 50
![Page 51: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/51.jpg)
Open Issue: Encrypted SNI
• SNI leaks the server’s identity
– Even if the server certificate is encrypted!
• would be nice to hide the SNI
– So hidden.com and innocuous.com could share a server
– Important for anti-censorship applications
• WG is still struggling with this
– General idea is to use the 0-RTT first flight to hide SNI
– But the details are complicated
– Looks like we can do this without major changes (and perhaps
none)
TLS 1.3 51
![Page 52: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/52.jpg)
Current Status
• Currently in draft-10
• Most major issues resolved at IETF Yokohama (two weeks ago)
• Formal models already starting to emerge
• Implementation in NSS (Firefox) by EOY
– OpenSSL, etc. to follow
• TLS Ready or Not Workshop in February (co-located with ISOC
NDSS)
• Expect Last Call in Q1
TLS 1.3 52
![Page 53: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/53.jpg)
Following the Work
• IETF TLS Mailing List:
https://www.ietf.org/mailman/listinfo/tls
• Github repository: https://github.com/tlswg/tls13-spec
• Editor’s draft: http://tlswg.github.io/tls13-spec/
TLS 1.3 53
![Page 54: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/54.jpg)
Questions?
TLS 1.3 54
![Page 55: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/55.jpg)
Extra Material
TLS 1.3 55
![Page 56: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/56.jpg)
Backward Compatibility Problems
1. What do you do if the other side doesn’t support RI?
• Server can refuse to renegotiate
• Client can only refuse to connect
– Guess what clients do...
2. Some servers are extension intolerant
• Extensions were defined after SSLv3 was already published
• Some servers choke on extensions
• ... badly
TLS 1.3 56
![Page 57: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/57.jpg)
Special Signaling Cipher Suites (I)
• OK, so the client can’t always send an extension
– What can it safely send?
TLS 1.3 57
![Page 58: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/58.jpg)
Special Signaling Cipher Suites (II)
• OK, so the client can’t always send an extension
– What can it safely send?
– ... a cipher suite
"IANA has added TLS cipher suite number 0x00,0xFF with name
TLS_EMPTY_RENEGOTIATION_INFO_SCSV to the TLS Cipher Suite registry."
- RFC5746
• Cipher suite negotiation code gets exercised regularly
• And got a workout when we added AES
– So it’s mostly safe to send new cipher suites
TLS 1.3 58
![Page 59: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/59.jpg)
TLS 1.2: (EC)DHE Skeleton
Client Server
ClientHello [Random] //ServerHello [Random], Certificate, Sign(Ks, gs, ...)oo
gc, Finished //
Finishedoo
oo Application data //
TLS 1.3 59
![Page 60: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/60.jpg)
TLS 1.2: (EC)DHE + Client Authentication
Client Server
ClientHello [Random] //ServerHello [Random], Certificate, CertificateRequest, Sign(Ks, gs, ...)oo
gc, Certificate, Sign(Kc, ...), Finished //
Finishedoo
oo Application data //
TLS 1.3 60
![Page 61: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/61.jpg)
References
[ABP+13] Nadhem J AlFardan, Daniel J Bernstein, Kenneth G Paterson,Bertram Poettering, and Jacob CN Schuldt. On the Securityof RC4 in TLS. In USENIX Security, pages 305–320, 2013.
[AP13] N AlFardan and Kenneth G Paterson. Lucky 13: Breakingthe TLS and DTLS record protocols. In IEEE Symposium onSecurity and Privacy, 2013.
[BLF+14] Karthikeyan Bhargavan, Antoine Delignat Lavaud, CedricFournet, Alfredo Pironti, and Pierre Yves Strub. Triple hand-shakes and cookie cutters: Breaking and fixing authenticationover tls. In Security and Privacy (SP), 2014 IEEE Symposiumon, pages 98–113. IEEE, 2014.
[BWBG+06] S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, andB. Moeller. Elliptic Curve Cryptography (ECC) Cipher Suites
TLS 1.3 60
![Page 62: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/62.jpg)
for Transport Layer Security (TLS). RFC 4492 (Informational),May 2006. Updated by RFCs 5246, 7027.
[CHvdMS] Cas Cremers, Marko Horvat, Thyla van der Merwe, andSam Scott. Revision 10: possible attack if client authen-tication is allowed during PSK. https://www.ietf.org/
mail-archive/web/tls/current/msg18215.html.
[DR12] Thai Duong and Juliano Rizzo. The crime attack. In Presen-tation at ekoparty Security Conference, 2012.
[Gil14] Daniel Kahn Gillmor. Negotiated Finite Field Diffie-HellmanEphemeral Parameters for TLS. Internet-Draft draft-ietf-tls-negotiated-ff-dhe, Internet Engineering Task Force, August2014. Work in progress.
[Lan10] Adam Langley. Transport Layer Security (TLS) Snap Start.Internet-Draft draft-agl-tls-snapstart-00, Internet EngineeringTask Force, June 2010. Work in progress.
TLS 1.3 60
![Page 63: TLS 1 - Stanford Universityweb.stanford.edu/class/ee380/Abstracts/151118-slides.pdf · 2015-11-20 · TLS 1.2 assumed that the client knew nothing { First round trip mostly consumed](https://reader030.vdocuments.us/reader030/viewer/2022040812/5e55df4ea657790591608d74/html5/thumbnails/63.jpg)
[PR14] Roberto Peon and Herve Ruellan. HPACK - Header Com-pression for HTTP/2. Internet-Draft draft-ietf-httpbis-header-compression-09, Internet Engineering Task Force, July 2014.Work in progress.
[RRDO10] E. Rescorla, M. Ray, S. Dispensa, and N. Oskov. TransportLayer Security (TLS) Renegotiation Indication Extension. RFC5746 (Proposed Standard), February 2010.
[SSL14] SSL Pulse. https://www.ssllabs.com/, Dec 2014.
TLS 1.3 60