diff --git a/index.html b/index.html
index 6cb46a4..d92a304 100644
--- a/index.html
+++ b/index.html
@@ -144,11 +144,11 @@ layout: false
 ## SSL, TLS, what's in a name?
 ]
 .right-column[
-SSL was originally developed by Netscape as a way to protect communications between browsers and web servers.
+SSL (Secure Socket Layer) was originally developed by Netscape as a way to protect communications between browsers and web servers.
 
 Then the browser wars started... No way other browser makers were going to using something that was branded by Netscape.
 
-SSL was from 1999(!) on developed further with the name TLS. So if you want to be pedantic, you can correct every use of `SSL` to `TLS`, and make lots of friends.
+SSL was from 1999(!) on developed further with the name TLS (Transport Layer Security). So if you want to be pedantic, you can correct every use of `SSL` to `TLS`, and make lots of friends.
 ]
 ---
 layout: false
@@ -156,8 +156,11 @@ layout: false
 ## So what is it really?
 ]
 .right-column[
-Well, it's kind of a secure tunnel protocol over TCP. But it does not really fit into the OSI model. Which does not really fit with TCP/IP to begin with, so let's just not care and have a look.
-<!-- XXX picture -->
+Well, it's kind of a secure tunnel protocol over TCP. But it does not really fit into the OSI model, or the TCP/IP model. Which does not really fit with eachother to begin with, so let's just not care and have a look.
+
+<img src="SSL-TLS-Layer-model.png"/>
+
+.footnote[Encapsulation in TCP/IP is a lot of fun. Boxes in boxes in boxes in boxes, etcetera.]
 ]
 ???
 $ openssl s_client -connect www.nu.nl:443
@@ -170,10 +173,10 @@ layout: false
 | Protocol | Published | Status |
 | ----------- | ----------- | -------- |
 | SSL 1.0 | Unpublished | Unpublished |
-| SSL 2.0 | 1995 |  Deprecated in 2011 (RFC 6176)  |
+| SSL 2.0 | 1995 |  Deprecated in 2011 (RFC 6176) |
 | SSL 3.0 | 1996 |  Deprecated in 2015 (RFC 7568) |
-| TLS 1.0 | 1999 |  Deprecation planned in 2020 |
-| TLS 1.1 | 2006 |  Deprecation planned in 2020 |
+| TLS 1.0 | 1999 |  Deprecated in 2021 (RFC 8996) |
+| TLS 1.1 | 2006 |  Deprecated in 2021 (RFC 8996) |
 | TLS 1.2 | 2008 | |
 | TLS 1.3 | 2018 | |
 
@@ -209,13 +212,15 @@ layout: false
 .right-column[
 A Man in the Middle attack is a situation where Alice wants to talk to Bob.
 
-<img src="alice-bob.png" width="100%" />
+<img src="alice-bob.png"/>
 
 And Carol figures out a way to get in between.
 
-<img src="alice-bob-carol.png" width="100%" />
+<img src="alice-bob-carol.png"/>
 
 This gives Carol full control over the conversation.
+
+.footnote[Cryptographers love calling everyone Alice, Bob, and Carol. It's a tradition.]
 ]
 
 ---
@@ -225,12 +230,13 @@ layout: false
 ]
 .right-column[
 To prevent a MitM attack, we need at least the following:
-- a way to establish that we are starting the conversation with the right endpoint
-- a way to make sure the conversation cannot be hijacked
+- A way to establish that we are starting the conversation with the right endpoint.
+  - This is solved using certificates.
 
-The first problem is solved by using certificates.
+- A way to make sure the conversation cannot be hijacked.
+  - This is solved by negotiating a session key (a shared secret) and encrypting the whole conversation using that key. This happens in the TLS handshake. [*]
 
-The second is solved by negotiating a session key (during the TLS handshake) and encrypting the whole conversation using that key.
+.footnote[[*] To me this still feels like magic. How can you get to a shared secret that Carol, while snooping the handshake, cannot know? We'll get back to that. No magic, I promise.]
 ]
 ---
 template: inverse
@@ -257,10 +263,9 @@ show certificate
 So, how does a certificate get signed?
 ]
 
-<img src="document-signing-process.png" width="100%" />
+<img src="document-signing-process.png" width="80%" />
 
 ???
-<!-- XXX picture -->
 Or how does this signing work:
 - take the unsigned certificate
 - calculate a hash of the certificate
@@ -274,9 +279,8 @@ Or how does this signing work:
 Now anyone can verify the signature:
 ]
 
-<img src="document-verify-signature.png" width="100%" />
+<img src="document-verify-signature.png" width="80%" />
 ???
-<!-- XXX picture -->
 Now anyone can verify the signature by:
 - decrypting the signature with the CAs public key
 - creating a hash of the website certificate
@@ -336,6 +340,17 @@ This is where the client and server decide on:
 9.    Secure symmetric encryption achieved: The handshake is completed, and communication continues using the session keys.
 ---
 .left-column[
+## Key exchange, no certificate?
+]
+.right-column[
+This is where the Diffie Hellman key exchange helps
+
+<img src="250px-Diffie-Hellman_Key_Exchange.svg.png" width="50%" />
+
+.footnote[Borrowed from: (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)]
+]
+---
+.left-column[
 ## TLS1.3
 ]
 .right-column[