Post on 18-Jan-2017
Automated Analysis of TLS 1.30-RTT, Resumption and Delayed Authentication
2 May 2016
CasCremers
MarkoHorvat
SamScott
Thylavan der Merwe
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
What we did (nutshell)
We built a symbolic model of the TLS 1.3 specification - draft10
We wanted to verify the main properties of TLS 1.3 as anauthenticated key exchange protocol
secrecy of session keysunilateral (mutual) authentication
We extended our draft 10 model to include the delayedauthentication mechanism
We found a potential attack - disclosed this to the IETF TLSWG
We started updating our model but the specification is amoving target
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Where our work fits in...
2011$ 2015$
1995$
1996$
1999$
2006$
2008$
2016$$$10$20
09$
2012$
2013$
2014$
1998$
2002$
Program'verifica-on'
Provable'security'
Formal'methods'
Dowling(et(al.([dra0105](Kohlweiss(et(al.([dra0105](Krawczyk(and(Wee([OPTLS](Dowling(et(al.([dra0110](
We'are'here!'
Ongoing(work(–later(talks(
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - draft 10
Ku,$Kd$
Data$Link$
Internet$
Transport$
Applica7on$ TLS$h:p$tcp$
hello, let’s chat
okay, let’s agree on algorithms, establish keys to communicate
securely and here’s some assurance as to my identity
Ku,$Kd$
let’s exchange application data
Handshake$protocol$
Record$protocol$
C S
Encrypt as much of the handshake as possibleRe-evaluate the handshake contents1-RTT for initial handshake and 0-RTT for repeatedhandshakesUpdate the record protection mechanisms
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - draft 10
Ku,$Kd$
Data$Link$
Internet$
Transport$
Applica7on$ TLS$h:p$tcp$
hello, let’s chat
okay, let’s agree on algorithms, establish keys to communicate
securely and here’s some assurance as to my identity
Ku,$Kd$
let’s exchange application data
Handshake$protocol$
Record$protocol$
C S
Session resumption merged with PSK mode
Delayed client authentication mechanism (draft 10+)
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - the OPTLS connection
OPTimized and/or One-Point-Three TLS, designed byKrawczyk and Wee
Meant as the basis for the TLS 1.3 handshake
Incorporates Pefect Forward Secrecy (PFS) and 0-RTTfunctionality
Designed to be flexible, simple, textbook crypto
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - the OPTLS connection
g^s$s%$derived$from$g^xs$atk$drived$from$g^xy$and$g^xs$
Source:$h9ps://eprint.iacr.org/2015/978.pdf$
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - the OPTLS connection
Source:(h*ps://eprint.iacr.org/2015/978.pdf(
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - the OPTLS connection
Source:(h*ps://eprint.iacr.org/2015/978.pdf(
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - draft 10
C S
ClientHello, ClientKeyShare
HelloRetryRequest
ClientHello, ClientKeyShare
ServerHello, ServerKeyShare, {EncryptedExtensions},{ServerConfiguration*},{Certificate}, {CertificateRequest*},{CertificateVerify}, {Finished}
{Certificate*}, {CertificateVerify*}, {Finished}
[Application data]
Initial (EC)DHE handshakeCas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - draft 10
C S
ClientHello, ClientKeyShare, EarlyDataIndication,(EncryptedExtensions), (Certificate*), (Certificate Verify*),(ApplicationData)
ServerHello, ServerKeyShare, EarlyDataIndication,{EncryptedExtensions}, {ServerConfiguration*},{Certificate}{CertificateRequest*}, {CertificateVerify}, {Finished}
{Finished}
[Application data]
0-RTT handshake
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - draft 10
C S
Initial handshake (see Figure (a))
[NewSessionTicket]
[Application data]
ClientHello, ClientKeyShare, PreSharedKeyExtension
ServerHello, PreSharedKeyExtension,{EncryptedExtensions}, {Finished}
{Finished}
[Application data]
PSK-resumption handshake
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - draft 10
Source: https://www.ietf.org/proceedings/93/slides/slides-93-tls-8.pdf
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - draft 10
TLS$1.2$and$below$ TLS$1.3$Ini$al'handshake'–'RSA,'DHE,'26RTT'
Ini$al'handshake'–'(EC)DHE'only,'16RTT'
Dedicated'resump$on'handshake'
Resump$on'via'PSK'handshake'
Dedicated'renego$a$on'handshake'
Dedicated'renego$a$on'handshake'removed'
No'early'data'func$onality' Early'data'–'06RTT'handshake'
Different set of handshakes!
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - draft 10
C S
ClientHello, ClientKeyShare
HelloRetryRequest
ClientHello, ClientKeyShare
ServerHello, ServerKeyShare, {EncryptedExtensions},{ServerConfiguration*},{Certificate}, {CertificateRequest*},{CertificateVerify}, {Finished}
{Certificate*}, {CertificateVerify*}, {Finished}
[Application data]
(a) Initial (EC)DHE handshake
C S
ClientHello, ClientKeyShare, EarlyDataIndication,(EncryptedExtensions), (Certificate*), (Certificate Verify*),(ApplicationData)
ServerHello, ServerKeyShare, EarlyDataIndication,{EncryptedExtensions}, {ServerConfiguration*},{Certificate}{CertificateRequest*}, {CertificateVerify}, {Finished}
{Finished}
[Application data]
(b) 0-RTT handshake
C S
Initial handshake (see Figure (a))
[NewSessionTicket]
[Application data]
ClientHello, ClientKeyShare, PreSharedKeyExtension
ServerHello, PreSharedKeyExtension,{EncryptedExtensions}, {Finished}
{Finished}
[Application data]
(c) PSK-resumption handshake(+ PSK-DHE)
Look at the full interaction of all these components!Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
TLS 1.3 - draft 10
C S
ClientHello, ClientKeyShare
HelloRetryRequest
ClientHello, ClientKeyShare
ServerHello, ServerKeyShare, {EncryptedExtensions},{ServerConfiguration*},{Certificate}, {CertificateRequest*},{CertificateVerify}, {Finished}
{Certificate*}, {CertificateVerify*}, {Finished}
[Application data]
(a) Initial (EC)DHE handshake
C S
ClientHello, ClientKeyShare, EarlyDataIndication,(EncryptedExtensions), (Certificate*), (Certificate Verify*),(ApplicationData)
ServerHello, ServerKeyShare, EarlyDataIndication,{EncryptedExtensions}, {ServerConfiguration*},{Certificate}{CertificateRequest*}, {CertificateVerify}, {Finished}
{Finished}
[Application data]
(b) 0-RTT handshake
C S
Initial handshake (see Figure (a))
[NewSessionTicket]
[Application data]
ClientHello, ClientKeyShare, PreSharedKeyExtension
ServerHello, PreSharedKeyExtension,{EncryptedExtensions}, {Finished}
{Finished}
[Application data]
(c) PSK-resumption handshake(+ PSK-DHE)
Look at the full interaction of all these components!Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Symbolic analysis
A symbolic model allows us to examine the logical soundness ofthe protocol
We systematically specify and hope to exclude a class ofattacks - ‘logical’ attacks (think Triple Handshake for TLS 1.2)
We assume black-box cryptography
We analyse the specification only
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Using Tamarin
Tool details available at:http://www.infsec.ethz.ch/research/software/tamarin.html
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Using Tamarin
We built our model for use in the Tamarin prover
Automated tool for protocol analysis
Good symbolic Diffie-Hellman support
Considers an unbounded number of parties/handshakes
How does it work?
For simple models/properties, can prove automatically
Complex models require more user interaction
A proof shows that a property holds in all possiblecombinations of client, server, and adversary behaviours
Tamarin is good because
We can precisely model the TLS state machines
We can accurately capture security properties
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Using Tamarin
We built our model for use in the Tamarin prover
Automated tool for protocol analysis
Good symbolic Diffie-Hellman support
Considers an unbounded number of parties/handshakes
How does it work?
For simple models/properties, can prove automatically
Complex models require more user interaction
A proof shows that a property holds in all possiblecombinations of client, server, and adversary behaviours
Tamarin is good because
We can precisely model the TLS state machines
We can accurately capture security properties
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Using Tamarin
We built our model for use in the Tamarin prover
Automated tool for protocol analysis
Good symbolic Diffie-Hellman support
Considers an unbounded number of parties/handshakes
How does it work?
For simple models/properties, can prove automatically
Complex models require more user interaction
A proof shows that a property holds in all possiblecombinations of client, server, and adversary behaviours
Tamarin is good because
We can precisely model the TLS state machines
We can accurately capture security properties
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
Encode honest party and adversary actions as Tamarin ‘rules’
For honest clients and servers rules correspond to flights ofmessages
Rules transition the protocol from one state to the next
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
rule C_1:
let
// Default C1 values
tid = ~nc
// Client Hello
C = $C
nc = ~nc
pc = $pc
S = $S
// Client Key Share
ga = ’g’^~a
messages = <nc, pc,ga>
in
[ Fr(nc)
, Fr(~a)
]
--[ C1(tid)
, Start(tid, C, ’client’)
, Running(C, S, ’client’, nc)
, DH(C, ~a)
]->
[ St_C_1_init(tid, C, nc, pc, S, ~a, messages, ’no_auth’)
, Out(<C,nc, pc,ga>)
]
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 1: Building a model
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 2: Encoding security properties
TLS 1.3 goals include:
unilateral authentication of the server (mandatory)
mutual authentication (optional)
confidentiality and perfect forward secrecy of session keys
We have Dolev-Yao style adversary that has the ability tocompromise long-term keys
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 2: Encoding security properties
Security property Covered by analysis SourceUnilateral authentication (server) Y D.1.1Mutual authentication Y D.1.1Confidentiality of ephemeral secret Y D.1.1Confidentiality of static secret Y D.1.1Perfect forward secrecy Y D.1.1.1Integrity of handshake messages Y D.1.3Protection of application data N D.2Denial of service N D.3Version rollback N D.1.2
Table : TLS 1.3 rev 10 properties
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 2: Encoding security properties
secret_session_keys:
(1) "All actor peer role k #i.
(2) SessionKey(actor, peer, role, <k, ’authenticated’>)@i
(3) & not ((Ex #r. RevLtk(peer)@r & #r < #i)
|(Ex #r. RevLtk(actor)@r & #r < #i))
(4) ==> not Ex #j. KU(k)@j"
This says...
for all possible values of variables on the first line (1),
if key k is accepted at time point i (2), and
the adversary has not revealed the long term keys of the actor or thepeer before the key is accepted (3),
then the adversary cannot derive the key (4).
Want to show that this holds for all combinations of client, server andadversary behaviours - ALL traces
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 2: Encoding security properties
secret_session_keys:
(1) "All actor peer role k #i.
(2) SessionKey(actor, peer, role, <k, ’authenticated’>)@i
(3) & not ((Ex #r. RevLtk(peer)@r & #r < #i)
|(Ex #r. RevLtk(actor)@r & #r < #i))
(4) ==> not Ex #j. KU(k)@j"
This says...
for all possible values of variables on the first line (1),
if key k is accepted at time point i (2), and
the adversary has not revealed the long term keys of the actor or thepeer before the key is accepted (3),
then the adversary cannot derive the key (4).
Want to show that this holds for all combinations of client, server andadversary behaviours - ALL traces
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 3: Proving security properties
SessionKey(….)
What can the adversary do?
S2
C2_Auth
What can the adversary do? ...and so on
eventually will boil down to
needing to break DH
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 3: Proving security properties
Not a straightforward application of Tamarin
several man-months of workspecification a moving targetupdating takes time, can be error-prone
Need an intimate knowledge of the protocol - high degree ofinteraction with the tool in some cases
Not a push-button analysis
We have 45 auxiliary lemmas
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 3: Proving security properties
secret_session_keys !
es_basic
psk_dhe_es_basic kc_origin
psk_helper psk_helper_client psk_helper_server
key_deriv_rs key_deriv_hkeys key_deriv_hkeyc psk_basic + many more
!
helpers!(proof!shortcuts)!
tid_invariant one_start_tid + many more
!
hints!
ss_basic
psk!helpers!
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Step 3: Proving security properties
We verified the main properties of TLS 1.3 revision 10 as anauthenticated key exchange protocol:
Secrecy of session keys
holds for both client and serverforward secrecy
Mutual authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication (draft 10+)
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C Auth
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
psk_id = psk_id
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Attacking client authentication
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Cause and mitigation
Prime example of an attack that can arise because of theinteraction of modes
No binding between the client signature and session for whichit is intended
Complicated to find
Example of the positive interaction of analysis and design
Communicated this to the IETF TLS Working Group...
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Cause and mitigation
https://www.ietf.org/mail-archive/web/tls/current/
msg18215.html
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Cause and mitigation
“Nice analysis! I think that the composition of different mechanismsin the protocol is likely to be where many subtle issues lie, andanalyses like this one support that concern.”
“Thanks for posting this. It’s great to see people doing real formalanalysis of the TLS 1.3 draft; this is really helpful in guiding thedesign.”
“This result motivates and confirms the need to modify thehandshake hashes to contain the server Finished when we addpost-handshake authentication as is done in PR#316...”
Although already included in PR316, the attack highlights strictnecessity of including the Finished message in the session hashand draft 11 does this - creates a binding between signature and thesession
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Cause and mitigation
“Nice analysis! I think that the composition of different mechanismsin the protocol is likely to be where many subtle issues lie, andanalyses like this one support that concern.”
“Thanks for posting this. It’s great to see people doing real formalanalysis of the TLS 1.3 draft; this is really helpful in guiding thedesign.”
“This result motivates and confirms the need to modify thehandshake hashes to contain the server Finished when we addpost-handshake authentication as is done in PR#316...”
Although already included in PR316, the attack highlights strictnecessity of including the Finished message in the session hashand draft 11 does this - creates a binding between signature and thesession
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Cause and mitigation
“Nice analysis! I think that the composition of different mechanismsin the protocol is likely to be where many subtle issues lie, andanalyses like this one support that concern.”
“Thanks for posting this. It’s great to see people doing real formalanalysis of the TLS 1.3 draft; this is really helpful in guiding thedesign.”
“This result motivates and confirms the need to modify thehandshake hashes to contain the server Finished when we addpost-handshake authentication as is done in PR#316...”
Although already included in PR316, the attack highlights strictnecessity of including the Finished message in the session hashand draft 11 does this - creates a binding between signature and thesession
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Cause and mitigation
“Nice analysis! I think that the composition of different mechanismsin the protocol is likely to be where many subtle issues lie, andanalyses like this one support that concern.”
“Thanks for posting this. It’s great to see people doing real formalanalysis of the TLS 1.3 draft; this is really helpful in guiding thedesign.”
“This result motivates and confirms the need to modify thehandshake hashes to contain the server Finished when we addpost-handshake authentication as is done in PR#316...”
Although already included in PR316, the attack highlights strictnecessity of including the Finished message in the session hashand draft 11 does this - creates a binding between signature and thesession
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Where we stand
We showed that draft 10 meets the goals of authenticated keyexchange, and the changes in draft 11 appear to address theattack
First comprehensive analysis of the interaction of the new TLS1.3 modes
we confirmed the base design is solidprevented a potential weakness
Draft 11...
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Where we stand
c0start
c1−dhe
c1−psk
c1−kc
c2a c2 c3
ClientHello Receive ServerHello/Finished +Send ClientFinished
Clientauthentication
C1
C 1 PSK
C 1 KC
C 2 PSK
C 2 PSK DHE
C 1 KC Auth
C 1 retry
C2
C 2 KC
C 2 NoAuth
C 2 Auth C 3
C 3 NST
C send
C Auth
C recv
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Where we stand
s0start
s1a−psk
s1a
s1 s2 s3
S1
S1KC
S1KC
RecvAuth
S1PS
K
S1PS
KDH
E S1PSK
AuthS1PSK
NoAuth
S1No
Auth
S1Au
thReq
S 1 retry
S 2
S 2 RecvAuth
S 2 Auth
S 3
S 3 NST
S send
S recv
S AuthReq
S RecvAuth
Process ClientHello +Send ServerHello
Update authen-tication state
Receive ClientFinished(with authentication)
Update authen-tication status
Got half-way through proving draft 11, then talk of major changes...
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Where we stand
Draft 12 adds 0.5-RTT data
But what’s next?
Talk on the mailing list and IETF meetings of
removing 0-RTT (EC)DHE handshakechanging the key schedule
Means that the specification starts to diverge from our currentmodel
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Where we stand
rev$10$ rev$10+$ rev$12$(inc.$11)$
rev$13,$14,$15..?$
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Making changes
The model can be updated to accommodate changes
Additions can complicate the analysis (adding loops)
Reductions/simplifications are easier to handle
Changes mean more man-hours
http://tls13tamarin.github.io/TLS13Tamarin/
Authors:
Cas Cremerscas.cremers@cs.ox.ac.uk
Sam Scottsam.scott.2012@live.rhul.ac.uk
Marko Horvatmarko.horvat@cs.ox.ac.uk
Thyla van der Merwethyla.vandermerwe.2012@live.rhul.ac.uk
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3
Making changes
The model can be updated to accommodate changes
Additions can complicate the analysis (adding loops)
Reductions/simplifications are easier to handle
Changes mean more man-hours
http://tls13tamarin.github.io/TLS13Tamarin/
Authors:
Cas Cremerscas.cremers@cs.ox.ac.uk
Sam Scottsam.scott.2012@live.rhul.ac.uk
Marko Horvatmarko.horvat@cs.ox.ac.uk
Thyla van der Merwethyla.vandermerwe.2012@live.rhul.ac.uk
Cas Cremers, Marko Horvat, Sam Scott, Thyla van der Merwe Automated Analysis of TLS 1.3