0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/566 Thanks! 1 00:00:09,950 --> 00:00:12,079 Now for the next talk, we 2 00:00:12,080 --> 00:00:14,449 will be learning about the state 3 00:00:14,450 --> 00:00:16,909 of email security in 2015, 4 00:00:16,910 --> 00:00:18,229 which is an important topic. 5 00:00:18,230 --> 00:00:20,299 As you all know, email is a 6 00:00:20,300 --> 00:00:22,669 thing that people use and 7 00:00:22,670 --> 00:00:24,529 email is also a thing that has lots of 8 00:00:24,530 --> 00:00:26,299 security problems. 9 00:00:26,300 --> 00:00:29,419 And our speaker today 10 00:00:29,420 --> 00:00:31,819 will be Sakia, who you might know 11 00:00:31,820 --> 00:00:33,889 as the developer of Seamap, which 12 00:00:33,890 --> 00:00:36,049 is a thing that allows you to map lots 13 00:00:36,050 --> 00:00:38,539 of beautiful IP addresses. 14 00:00:38,540 --> 00:00:39,829 And I think more recently was also 15 00:00:39,830 --> 00:00:42,439 involved in Log Jam, 16 00:00:42,440 --> 00:00:44,359 which is not a security nightmare on its 17 00:00:44,360 --> 00:00:46,770 own. So please welcome Zacchia. 18 00:00:48,410 --> 00:00:49,410 Thank you. 19 00:00:54,310 --> 00:00:55,599 Well, thank you for the introduction. 20 00:00:55,600 --> 00:00:56,979 It's good to be back here again this 21 00:00:56,980 --> 00:00:59,169 year, so I mostly want 22 00:00:59,170 --> 00:01:00,759 to look at today, how is your email 23 00:01:00,760 --> 00:01:01,749 protected? 24 00:01:01,750 --> 00:01:03,549 When we talk about email security being 25 00:01:03,550 --> 00:01:04,719 the first thing that comes to a lot of 26 00:01:04,720 --> 00:01:06,789 people's minds is PGP 27 00:01:06,790 --> 00:01:08,679 or mine views end to end encryption 28 00:01:08,680 --> 00:01:09,729 technologies. 29 00:01:09,730 --> 00:01:11,829 But the reality is a minuscule amount 30 00:01:11,830 --> 00:01:14,199 of emails actually encrypted using PGP. 31 00:01:14,200 --> 00:01:16,299 And even if you are using PGP, all your 32 00:01:16,300 --> 00:01:18,849 metadata still sent in the clear. 33 00:01:18,850 --> 00:01:21,069 And so what happens for all the email 34 00:01:21,070 --> 00:01:23,259 we send on a daily basis that doesn't use 35 00:01:23,260 --> 00:01:24,429 PGP? 36 00:01:24,430 --> 00:01:26,829 Well, on the back end, mail operators 37 00:01:26,830 --> 00:01:28,659 have deployed a range of protocols to 38 00:01:28,660 --> 00:01:30,399 help secure mail to authenticate 39 00:01:30,400 --> 00:01:32,379 authenticate mail that you receive. 40 00:01:32,380 --> 00:01:34,089 So today I want to talk about what those 41 00:01:34,090 --> 00:01:36,219 protocols are, essentially how 42 00:01:36,220 --> 00:01:37,869 we've come along in time, how well 43 00:01:37,870 --> 00:01:39,069 they're deployed today. 44 00:01:39,070 --> 00:01:40,509 And then the attacks that we're seeing in 45 00:01:40,510 --> 00:01:42,069 the wild against mail servers. 46 00:01:43,480 --> 00:01:45,609 And the content in this talk is actually 47 00:01:45,610 --> 00:01:47,679 based on a large collaboration between 48 00:01:47,680 --> 00:01:49,179 the University of Michigan, the 49 00:01:49,180 --> 00:01:52,059 University of Illinois and Google. 50 00:01:52,060 --> 00:01:53,649 And so the data we're looking at in this 51 00:01:53,650 --> 00:01:55,329 talk is either based on Internet wide 52 00:01:55,330 --> 00:01:57,309 scanning or essentially the email that 53 00:01:57,310 --> 00:01:59,589 came to and from Gmail in the past two 54 00:01:59,590 --> 00:02:00,590 years. 55 00:02:02,060 --> 00:02:04,189 So when I say email delivery 56 00:02:04,190 --> 00:02:06,019 security, what am I talking about? 57 00:02:06,020 --> 00:02:07,639 Well, if we start at the very beginning 58 00:02:07,640 --> 00:02:09,529 and we just say, well, how does how does 59 00:02:09,530 --> 00:02:10,969 it work? 60 00:02:10,970 --> 00:02:13,129 When used to mean email, usually you 61 00:02:13,130 --> 00:02:14,809 send us from your laptop, you send it to 62 00:02:14,810 --> 00:02:17,599 your organizations, some TP server. 63 00:02:17,600 --> 00:02:19,129 This may just be something that your 64 00:02:19,130 --> 00:02:21,289 department or your company runs. 65 00:02:21,290 --> 00:02:23,619 And this is submitted over some TPE, 66 00:02:23,620 --> 00:02:25,580 but as we call it, some type submission 67 00:02:26,870 --> 00:02:28,909 and it gets that server and server hangs 68 00:02:28,910 --> 00:02:30,169 on to it and essentially then takes 69 00:02:30,170 --> 00:02:32,179 responsibility for getting it to the 70 00:02:32,180 --> 00:02:34,039 destination organization. 71 00:02:34,040 --> 00:02:36,049 So your SMTP server and your local 72 00:02:36,050 --> 00:02:38,119 organization does a DNS look 73 00:02:38,120 --> 00:02:39,799 up for the Amex record for the domain 74 00:02:39,800 --> 00:02:41,030 you're trying to send the email to, 75 00:02:42,050 --> 00:02:43,549 and it gets back eventually in name of 76 00:02:43,550 --> 00:02:45,619 email server and an IP address 77 00:02:45,620 --> 00:02:47,959 and then your local TPE 78 00:02:47,960 --> 00:02:49,789 server, your organization delivers the 79 00:02:49,790 --> 00:02:52,019 email to the destination organization 80 00:02:52,020 --> 00:02:54,259 server, which holds on to it 81 00:02:54,260 --> 00:02:56,629 until later on this hour, comes 82 00:02:56,630 --> 00:02:58,849 and collects using Pop three or 83 00:02:58,850 --> 00:03:00,439 IMAP or three the web interface 84 00:03:01,670 --> 00:03:03,259 in the first thing. The last step in this 85 00:03:03,260 --> 00:03:05,449 process uses 86 00:03:05,450 --> 00:03:08,149 Telos very much in the way that https 87 00:03:08,150 --> 00:03:10,249 is to for keeps your 88 00:03:10,250 --> 00:03:11,809 client connects to verifies the 89 00:03:11,810 --> 00:03:12,739 certificate. 90 00:03:12,740 --> 00:03:14,299 You can say I'm only going to connect 91 00:03:14,300 --> 00:03:16,429 over HSDPA, so I'm only going 92 00:03:16,430 --> 00:03:18,679 to connect using class. 93 00:03:18,680 --> 00:03:20,809 What I want to focus on today actually 94 00:03:20,810 --> 00:03:22,429 is the other part, the part in the 95 00:03:22,430 --> 00:03:24,409 middle, and this is the part that goes 96 00:03:24,410 --> 00:03:25,699 over essentially the Internet. 97 00:03:25,700 --> 00:03:27,829 How do you communicate mail from your one 98 00:03:27,830 --> 00:03:30,320 organization to the next organization? 99 00:03:31,340 --> 00:03:33,439 And by default, at the beginning, 100 00:03:33,440 --> 00:03:35,569 as S&P was originally conceived, there is 101 00:03:35,570 --> 00:03:38,239 absolutely no security built in. 102 00:03:38,240 --> 00:03:40,339 Everything was sent in the clear text 103 00:03:40,340 --> 00:03:41,899 and you trusted every email that you 104 00:03:41,900 --> 00:03:44,419 received came from the original sender. 105 00:03:44,420 --> 00:03:46,459 And over the years, we realized this was 106 00:03:46,460 --> 00:03:48,529 actually probably not exactly 107 00:03:48,530 --> 00:03:50,329 what we wanted for our email, one of the 108 00:03:50,330 --> 00:03:52,549 technologies we use for some of our 109 00:03:52,550 --> 00:03:54,769 most trusted communication. 110 00:03:54,770 --> 00:03:56,479 And so we added in essentially these 111 00:03:56,480 --> 00:03:58,549 extensions to some TCP 112 00:03:58,550 --> 00:04:00,139 and these allow these more security 113 00:04:00,140 --> 00:04:01,399 features. They allowed us to encrypt 114 00:04:01,400 --> 00:04:02,929 email and translate. They allowed us to 115 00:04:02,930 --> 00:04:04,639 authenticate the types of emails that we 116 00:04:04,640 --> 00:04:05,599 receive. 117 00:04:05,600 --> 00:04:07,639 However, none of you have probably ever 118 00:04:07,640 --> 00:04:09,289 seen these technologies unless you're an 119 00:04:09,290 --> 00:04:10,609 actual mail operator. 120 00:04:10,610 --> 00:04:12,739 All of this is invisible to the end 121 00:04:12,740 --> 00:04:14,209 user. You don't know if your email is 122 00:04:14,210 --> 00:04:16,159 encrypted. When it was sent from my 123 00:04:16,160 --> 00:04:18,229 university to your university, you don't 124 00:04:18,230 --> 00:04:19,398 know if your university actually 125 00:04:19,399 --> 00:04:20,898 authenticated the email before it 126 00:04:20,899 --> 00:04:22,159 delivered it to you. 127 00:04:22,160 --> 00:04:23,569 And so today we want to look at, well, 128 00:04:23,570 --> 00:04:25,309 how well actually does this happen in 129 00:04:25,310 --> 00:04:26,310 practice? 130 00:04:27,230 --> 00:04:29,299 So the first protocol that comes to 131 00:04:29,300 --> 00:04:31,459 mind is probably the most well known 132 00:04:31,460 --> 00:04:33,709 is start class and essentially 133 00:04:33,710 --> 00:04:36,649 start classes to illustrate some TPE. 134 00:04:36,650 --> 00:04:38,779 And what it allows is essentially for 135 00:04:38,780 --> 00:04:40,099 the message should be encrypted in 136 00:04:40,100 --> 00:04:42,259 transit when it goes over the Internet. 137 00:04:42,260 --> 00:04:44,419 And the protocol is pretty simple. 138 00:04:44,420 --> 00:04:47,029 You actually start a normal ENTP session 139 00:04:47,030 --> 00:04:48,499 like you would if you're sending a 140 00:04:48,500 --> 00:04:50,569 message and clear text, 141 00:04:50,570 --> 00:04:52,319 you create you start TCAP handshake. 142 00:04:52,320 --> 00:04:54,979 I'm twenty five, you send a hello. 143 00:04:54,980 --> 00:04:56,719 The server then responds to the features 144 00:04:56,720 --> 00:04:58,189 that it supports and what those features 145 00:04:58,190 --> 00:05:00,169 are going to be. Start RTLS. 146 00:05:00,170 --> 00:05:02,779 So then you send this start to command. 147 00:05:02,780 --> 00:05:04,549 The service has great I support start to 148 00:05:04,550 --> 00:05:06,259 you and then you do a normal Tlas 149 00:05:06,260 --> 00:05:07,699 handshake. You send a client. 150 00:05:07,700 --> 00:05:08,959 Hello, the server sends a server. 151 00:05:08,960 --> 00:05:10,789 Hello. You complete the whole handshake 152 00:05:10,790 --> 00:05:12,889 after which this negotiation finishes, 153 00:05:12,890 --> 00:05:15,049 you are back and S&P and you can deliver 154 00:05:15,050 --> 00:05:17,279 your mail and it's sent over this 155 00:05:17,280 --> 00:05:18,280 session. 156 00:05:18,770 --> 00:05:20,059 However, this is done a little bit 157 00:05:20,060 --> 00:05:23,209 differently than this is done in TDP. 158 00:05:23,210 --> 00:05:25,669 And one of the reasons is, is that 159 00:05:25,670 --> 00:05:27,799 the way we use to lessen ENTP 160 00:05:27,800 --> 00:05:29,809 is opportunistic. 161 00:05:29,810 --> 00:05:32,179 And the main reason is, is because the RC 162 00:05:32,180 --> 00:05:34,459 actually says a server may not 163 00:05:34,460 --> 00:05:36,709 require that mail be sent over 164 00:05:36,710 --> 00:05:38,509 an encrypted channel. It may not require 165 00:05:38,510 --> 00:05:40,609 that to be used. 166 00:05:40,610 --> 00:05:42,799 So that means that if it can't 167 00:05:42,800 --> 00:05:44,569 be used, then your only alternative is to 168 00:05:44,570 --> 00:05:45,679 sending clear text. 169 00:05:47,180 --> 00:05:49,069 So because of this service, do not 170 00:05:49,070 --> 00:05:51,559 validate any destination certificates. 171 00:05:51,560 --> 00:05:53,239 They get the certificate and they 172 00:05:53,240 --> 00:05:54,199 essentially discard it. 173 00:05:54,200 --> 00:05:55,969 They don't really look at it because if 174 00:05:55,970 --> 00:05:57,199 they looked at it, they realized they 175 00:05:57,200 --> 00:05:58,639 don't like it, it's expired. 176 00:05:58,640 --> 00:06:00,619 Then the alternative is to send a message 177 00:06:00,620 --> 00:06:02,779 in clear text, which is really not any 178 00:06:02,780 --> 00:06:04,759 better than just sending the certificate 179 00:06:04,760 --> 00:06:06,379 over an encrypted channel, thus using an 180 00:06:06,380 --> 00:06:07,759 expired certificate. 181 00:06:07,760 --> 00:06:09,589 So at the end of the day, nobody 182 00:06:09,590 --> 00:06:10,999 validates any certificates. 183 00:06:11,000 --> 00:06:12,799 And because of that, essentially nobody 184 00:06:12,800 --> 00:06:14,989 really provisional certificates, 185 00:06:14,990 --> 00:06:16,829 people just a self signed cert and never 186 00:06:16,830 --> 00:06:18,499 will trust it. And no one's the wiser at 187 00:06:18,500 --> 00:06:19,500 the end of the day. 188 00:06:20,450 --> 00:06:22,699 And in the end, we 189 00:06:22,700 --> 00:06:24,979 aren't in the position to essentially 190 00:06:24,980 --> 00:06:27,109 require start to from all servers 191 00:06:27,110 --> 00:06:29,359 because so many don't support it yet. 192 00:06:29,360 --> 00:06:30,469 We'll get into this a little bit later 193 00:06:30,470 --> 00:06:31,470 when we look at data. 194 00:06:32,480 --> 00:06:34,789 But it's actually even more complicated 195 00:06:34,790 --> 00:06:36,319 than that, because even if one hundred 196 00:06:36,320 --> 00:06:38,509 percent of servers supported start 197 00:06:38,510 --> 00:06:40,759 to less, there's still an additional 198 00:06:40,760 --> 00:06:42,290 layer of essentially 199 00:06:43,460 --> 00:06:45,559 redirection within some top. 200 00:06:45,560 --> 00:06:47,839 And that's because unlike 201 00:06:47,840 --> 00:06:49,459 when you go to a domain, you get an IP 202 00:06:49,460 --> 00:06:49,759 address. 203 00:06:49,760 --> 00:06:51,979 Right back when I say I want to send 204 00:06:51,980 --> 00:06:54,079 an email to Gmail dot com, I go 205 00:06:54,080 --> 00:06:55,759 and I do this and record look up for 206 00:06:55,760 --> 00:06:57,859 Gmail dot com and I essentially get back 207 00:06:57,860 --> 00:06:59,989 a list of names in this might be 208 00:06:59,990 --> 00:07:01,309 like S.A.G.. 209 00:07:01,310 --> 00:07:03,409 Gmail dot com, and then I go and I 210 00:07:03,410 --> 00:07:05,539 do a second DNS look up for 211 00:07:05,540 --> 00:07:07,609 what is the IP address for some TP dot 212 00:07:07,610 --> 00:07:10,009 Gmail dot com and eventually I transmit 213 00:07:10,010 --> 00:07:12,529 mail to that IP address. 214 00:07:12,530 --> 00:07:13,879 So you say, well, what do you put on the 215 00:07:13,880 --> 00:07:14,899 certificate? 216 00:07:14,900 --> 00:07:16,159 Well, you could you have two options. 217 00:07:16,160 --> 00:07:18,259 You could put the name of the actual ENTP 218 00:07:18,260 --> 00:07:20,209 server itself, S&P, A.P., that Gmail dot 219 00:07:20,210 --> 00:07:22,639 com. Or we could put the actual domain 220 00:07:22,640 --> 00:07:23,640 Gmail dot com 221 00:07:24,710 --> 00:07:26,509 put in the name of the of the server 222 00:07:26,510 --> 00:07:27,769 itself, doesn't actually really do 223 00:07:27,770 --> 00:07:30,259 anything for us, because if you are 224 00:07:30,260 --> 00:07:31,789 being man in the middle, if you're being 225 00:07:31,790 --> 00:07:33,889 attacked when you went to request the 226 00:07:33,890 --> 00:07:35,749 name of this Amex record, essentially 227 00:07:35,750 --> 00:07:37,879 your DNS server would lie to you. 228 00:07:37,880 --> 00:07:39,439 The attacker would provide you a false 229 00:07:39,440 --> 00:07:41,509 name, and then you would go ahead and use 230 00:07:41,510 --> 00:07:42,769 it and your certificate would match the 231 00:07:42,770 --> 00:07:44,959 false name, but still be provided by 232 00:07:44,960 --> 00:07:46,369 the attacker. 233 00:07:46,370 --> 00:07:47,989 And so the alternative, on the other 234 00:07:47,990 --> 00:07:49,429 hand, that makes, I think, more sense to 235 00:07:49,430 --> 00:07:50,929 all of us off hand as well. 236 00:07:50,930 --> 00:07:52,819 Put the actual domain itself, put Gmail 237 00:07:52,820 --> 00:07:54,499 dot com on the certificate, on the mail 238 00:07:54,500 --> 00:07:56,329 server, and then we know are connecting 239 00:07:56,330 --> 00:07:57,330 to the real server. 240 00:07:58,580 --> 00:08:00,709 But a huge number of people essentially 241 00:08:00,710 --> 00:08:02,359 delegate their email out. 242 00:08:02,360 --> 00:08:04,159 These are the mail providers for the top 243 00:08:04,160 --> 00:08:06,619 million domains, the Aleksa list 244 00:08:06,620 --> 00:08:08,929 and approximately twenty 245 00:08:08,930 --> 00:08:10,639 five percent of these actually delegates 246 00:08:10,640 --> 00:08:11,980 their email out to someone else. 247 00:08:13,100 --> 00:08:15,169 And so all of a sudden, Gmail, if Gmail 248 00:08:15,170 --> 00:08:17,179 needs a certificate that's going to match 249 00:08:17,180 --> 00:08:18,949 the domain of the email you're sending to 250 00:08:18,950 --> 00:08:21,829 also needs to have 251 00:08:21,830 --> 00:08:24,139 a certificate that matches six percent 252 00:08:24,140 --> 00:08:26,599 of domains on the Internet, potentially. 253 00:08:26,600 --> 00:08:28,189 And it's not to say this is entirely 254 00:08:28,190 --> 00:08:29,539 infeasible, that we could create 255 00:08:29,540 --> 00:08:31,099 technology that handles this, that we 256 00:08:31,100 --> 00:08:32,689 could create some sort of constrained 257 00:08:32,690 --> 00:08:35,479 certificate that is not immediately 258 00:08:35,480 --> 00:08:37,038 obvious how to do this today. 259 00:08:37,039 --> 00:08:38,449 There isn't an immediate solution where 260 00:08:38,450 --> 00:08:40,279 we can start to acquire start tools. 261 00:08:42,250 --> 00:08:44,379 So if we start to 262 00:08:44,380 --> 00:08:46,479 look at data, this is 263 00:08:46,480 --> 00:08:48,609 the essentially the amount of messages 264 00:08:48,610 --> 00:08:51,609 in and out of Gmail 265 00:08:51,610 --> 00:08:54,039 that you start to lose, 266 00:08:54,040 --> 00:08:56,649 and we're actually have made significant 267 00:08:56,650 --> 00:08:58,539 progress over the last two years. 268 00:08:58,540 --> 00:09:01,029 And we're at the point where nearly 269 00:09:01,030 --> 00:09:03,099 80 percent of messages 270 00:09:03,100 --> 00:09:05,499 that are outbound, we're able to initiate 271 00:09:05,500 --> 00:09:07,779 connections for and just over 60 272 00:09:07,780 --> 00:09:10,119 percent of inbound connections initiate a 273 00:09:10,120 --> 00:09:11,120 lost connection. 274 00:09:11,920 --> 00:09:13,599 However, at the same time, this was 275 00:09:13,600 --> 00:09:16,089 actually due to a couple of very large 276 00:09:16,090 --> 00:09:18,099 providers changing their start to 277 00:09:18,100 --> 00:09:19,029 policies. 278 00:09:19,030 --> 00:09:20,859 There's this very, very large jump in 279 00:09:20,860 --> 00:09:23,079 early 2014 that essentially 280 00:09:23,080 --> 00:09:23,799 is when Yahoo! 281 00:09:23,800 --> 00:09:26,229 And Hotmail diploid start to lose. 282 00:09:26,230 --> 00:09:27,789 And so it's actually once you remove 283 00:09:27,790 --> 00:09:30,069 these, it's rather 284 00:09:30,070 --> 00:09:31,539 stagnant. 285 00:09:31,540 --> 00:09:32,979 We are slowly increasing. 286 00:09:32,980 --> 00:09:34,509 There are small number of servers are 287 00:09:34,510 --> 00:09:36,849 slowly adopting these new protocols. 288 00:09:36,850 --> 00:09:38,529 But it's not like we're making these 289 00:09:38,530 --> 00:09:39,549 major leaps. 290 00:09:39,550 --> 00:09:40,779 These are actually just due to these 291 00:09:40,780 --> 00:09:42,579 small handful of providers that everyone 292 00:09:42,580 --> 00:09:43,580 uses. 293 00:09:44,350 --> 00:09:45,999 And when we zoom in, it's actually a very 294 00:09:46,000 --> 00:09:47,889 interesting graph here. 295 00:09:47,890 --> 00:09:49,599 You'll notice actually, you see it kind 296 00:09:49,600 --> 00:09:50,739 of goes up and down, up and down. 297 00:09:50,740 --> 00:09:52,629 And these are actually weekdays versus 298 00:09:52,630 --> 00:09:54,009 weekends. 299 00:09:54,010 --> 00:09:56,889 So for all email that comes in Gmail, 300 00:09:56,890 --> 00:09:59,499 we see about 10 percent more email is 301 00:09:59,500 --> 00:10:01,569 that comes inbound, is encrypted on 302 00:10:01,570 --> 00:10:03,789 weekends than on weekdays. 303 00:10:03,790 --> 00:10:05,259 And we suspect that this is because 304 00:10:05,260 --> 00:10:06,429 people go home and they use their 305 00:10:06,430 --> 00:10:08,529 personal email accounts they send from 306 00:10:08,530 --> 00:10:09,969 their Hotmail account to their friends at 307 00:10:09,970 --> 00:10:11,859 Gmail, and then they go back to work 308 00:10:11,860 --> 00:10:13,029 during the weekdays. 309 00:10:13,030 --> 00:10:14,679 And the emails they send at work are 310 00:10:14,680 --> 00:10:16,059 actually less secure than all the 311 00:10:16,060 --> 00:10:17,319 personal emails they send on the 312 00:10:17,320 --> 00:10:18,320 weekends. 313 00:10:21,580 --> 00:10:23,739 As well, it's a fragile, fragile 314 00:10:23,740 --> 00:10:24,729 ecosystem. 315 00:10:24,730 --> 00:10:26,979 You see this big jump where we lose 316 00:10:26,980 --> 00:10:29,229 close to 20 percent of email being 317 00:10:29,230 --> 00:10:31,599 encrypted when Puddle came out, which 318 00:10:31,600 --> 00:10:33,399 from as far as we can tell, is just 319 00:10:33,400 --> 00:10:35,259 because people panicked and they try to 320 00:10:35,260 --> 00:10:37,809 disable SSL free and they just 321 00:10:37,810 --> 00:10:39,129 disabled all tools. 322 00:10:40,420 --> 00:10:42,159 And the slowly recovered, we started to 323 00:10:42,160 --> 00:10:43,359 encrypt email again. 324 00:10:43,360 --> 00:10:46,359 But this is not what we want to see. 325 00:10:46,360 --> 00:10:49,509 This is this is kind of a mess going on. 326 00:10:49,510 --> 00:10:52,479 And even for the big providers today, 327 00:10:52,480 --> 00:10:55,239 we're using bizarre ciphers, 328 00:10:55,240 --> 00:10:57,519 even for these top providers of email 329 00:10:57,520 --> 00:10:58,659 on the Internet. 330 00:10:58,660 --> 00:11:01,149 We're still negotiating Arcy for Facebook 331 00:11:01,150 --> 00:11:02,589 mail, still has a certificate that 332 00:11:02,590 --> 00:11:03,660 doesn't match anything. 333 00:11:04,780 --> 00:11:06,129 They have a signed certificate. 334 00:11:06,130 --> 00:11:08,169 It's valid just not for domain that has 335 00:11:08,170 --> 00:11:09,880 anything to do with their mail servers. 336 00:11:12,420 --> 00:11:14,219 And we're talking the top 10 in the world 337 00:11:14,220 --> 00:11:15,220 of Sendmail, 338 00:11:17,130 --> 00:11:19,649 and we actually just validators and AT&T 339 00:11:19,650 --> 00:11:20,069 and Yahoo! 340 00:11:20,070 --> 00:11:22,109 Are still initiating ask for connections 341 00:11:22,110 --> 00:11:23,110 as of this morning. 342 00:11:25,760 --> 00:11:27,949 This is not better for the long tail 343 00:11:27,950 --> 00:11:30,049 of people, not in these top 10 in the top 344 00:11:30,050 --> 00:11:32,359 most popular of the top 345 00:11:32,360 --> 00:11:34,639 million domains, about 80 percent support 346 00:11:34,640 --> 00:11:36,019 start to less. 347 00:11:36,020 --> 00:11:38,119 About 34 percent have certificates that 348 00:11:38,120 --> 00:11:39,829 match the server but don't really provide 349 00:11:39,830 --> 00:11:40,819 any security. 350 00:11:40,820 --> 00:11:43,039 And only zero point six percent have 351 00:11:43,040 --> 00:11:45,019 a certificate that matches the domain 352 00:11:45,020 --> 00:11:47,089 such that you could actually validate 353 00:11:47,090 --> 00:11:48,679 that you were sending mail to the right 354 00:11:48,680 --> 00:11:49,730 person on the Internet. 355 00:11:51,810 --> 00:11:53,519 So how did we end up in the state? 356 00:11:53,520 --> 00:11:55,199 This is kind of sad. 357 00:11:55,200 --> 00:11:57,569 If you go back and you look at 358 00:11:57,570 --> 00:11:59,279 the common meal software that's being 359 00:11:59,280 --> 00:12:00,899 used, a lot of these software don't 360 00:12:00,900 --> 00:12:02,909 provide start to collapse by default. 361 00:12:02,910 --> 00:12:05,189 In fact, the only people who actually do 362 00:12:05,190 --> 00:12:06,930 both is Microsoft Exchange, 363 00:12:08,250 --> 00:12:09,250 which is. 364 00:12:14,820 --> 00:12:16,919 And there is some work to do default 365 00:12:16,920 --> 00:12:19,079 in coming start tells you you need to 366 00:12:19,080 --> 00:12:20,909 generate a certificate, you need to get 367 00:12:20,910 --> 00:12:23,039 this set up. But for outgoing class, 368 00:12:23,040 --> 00:12:25,319 there's really absolutely no reason 369 00:12:25,320 --> 00:12:27,029 that postfix and Kumail are not 370 00:12:27,030 --> 00:12:29,099 initiating start connections by 371 00:12:29,100 --> 00:12:30,100 default. 372 00:12:30,900 --> 00:12:32,129 So at the end of the day, what this 373 00:12:32,130 --> 00:12:34,379 really boils down to is start 374 00:12:34,380 --> 00:12:36,269 to less is protecting against passes, 375 00:12:36,270 --> 00:12:38,459 eavesdropping, but it protects 376 00:12:38,460 --> 00:12:40,479 against nothing else. 377 00:12:40,480 --> 00:12:42,149 It does not protect against any sort of 378 00:12:42,150 --> 00:12:43,150 active attacks. 379 00:12:44,190 --> 00:12:47,219 So let's say I'm an active attacker 380 00:12:47,220 --> 00:12:49,469 and I want to disable start to 381 00:12:49,470 --> 00:12:51,809 lose. What is the simplest way 382 00:12:51,810 --> 00:12:53,369 that I can eavesdrop on all these servers 383 00:12:53,370 --> 00:12:54,479 that you start to less? 384 00:12:56,930 --> 00:12:59,089 Well, the easiest way of doing 385 00:12:59,090 --> 00:13:01,159 this is you watch for some TP 386 00:13:01,160 --> 00:13:03,349 connections and you see this start 387 00:13:03,350 --> 00:13:05,429 to last command and you just replace 388 00:13:05,430 --> 00:13:06,470 it with a bunch of gibberish. 389 00:13:08,060 --> 00:13:10,009 And so I go and I say, hello, mail 390 00:13:10,010 --> 00:13:11,449 server, and what do you support? 391 00:13:11,450 --> 00:13:13,729 And you say, I support compression 392 00:13:13,730 --> 00:13:16,189 and I support ENTP 393 00:13:16,190 --> 00:13:19,279 and I support Zak's. 394 00:13:19,280 --> 00:13:20,659 And the client says, great, I don't know 395 00:13:20,660 --> 00:13:22,189 what that is, I won't use it. 396 00:13:22,190 --> 00:13:23,479 And that sends clear text mail. 397 00:13:24,890 --> 00:13:27,049 Now, the client could say, OK, I'm 398 00:13:27,050 --> 00:13:28,309 going to ignore that. I'm going to send 399 00:13:28,310 --> 00:13:30,619 start Helus anyway, at which point 400 00:13:30,620 --> 00:13:32,689 the attacker just replaces start 401 00:13:32,690 --> 00:13:34,909 with Zak's, it gets the server 402 00:13:34,910 --> 00:13:36,469 in the server says, I have no idea what 403 00:13:36,470 --> 00:13:37,579 you want from me. 404 00:13:37,580 --> 00:13:39,739 Why are you sending me access in? 405 00:13:39,740 --> 00:13:42,169 This sounds like the dumbest 406 00:13:42,170 --> 00:13:43,999 attack you could come up with, right. 407 00:13:44,000 --> 00:13:46,129 Like why would you not man in the middle. 408 00:13:46,130 --> 00:13:47,479 Why would you not do something a little 409 00:13:47,480 --> 00:13:48,480 bit stealthier? 410 00:13:49,340 --> 00:13:51,079 But we didn't internet white scans and we 411 00:13:51,080 --> 00:13:52,759 looked for this. We looked at how what 412 00:13:52,760 --> 00:13:54,649 percentage of messages were actually 413 00:13:54,650 --> 00:13:56,749 garbled and we looked at what percentage 414 00:13:56,750 --> 00:13:58,669 of email to and from Gmail 415 00:13:59,750 --> 00:14:01,939 essentially were from these ISPs. 416 00:14:01,940 --> 00:14:03,169 And it's astounding. 417 00:14:07,320 --> 00:14:09,429 So let's take a moment, let's think in 418 00:14:11,310 --> 00:14:13,350 96 percent of emails 419 00:14:14,400 --> 00:14:16,739 from Tunisia are blocked 420 00:14:16,740 --> 00:14:18,899 from starting a last session to 421 00:14:18,900 --> 00:14:21,239 encrypt mail by some sort of network 422 00:14:21,240 --> 00:14:23,399 device in between, that takes the start 423 00:14:23,400 --> 00:14:25,229 to command and corrupts it. 424 00:14:27,520 --> 00:14:30,249 So these are the top 10 countries, 425 00:14:30,250 --> 00:14:32,289 if we look at the top 20, you start to 426 00:14:32,290 --> 00:14:33,889 see European nations. 427 00:14:33,890 --> 00:14:35,619 We keep going, we see almost every 428 00:14:35,620 --> 00:14:36,620 nation. 429 00:14:38,120 --> 00:14:40,309 And you wonder why why 430 00:14:40,310 --> 00:14:42,619 is this happening, is this malicious? 431 00:14:42,620 --> 00:14:44,149 Are these countries are these nation 432 00:14:44,150 --> 00:14:45,979 states that are decrypting mail? 433 00:14:45,980 --> 00:14:47,779 What is going on here? 434 00:14:47,780 --> 00:14:50,269 And it's not immediately obvious 435 00:14:50,270 --> 00:14:51,379 when you break down the types of 436 00:14:51,380 --> 00:14:54,169 organizations, you see everything. 437 00:14:54,170 --> 00:14:56,419 But you also find is Cisco actually 438 00:14:56,420 --> 00:14:58,019 advertises this as a feature. 439 00:14:59,480 --> 00:15:01,669 So what happens 440 00:15:01,670 --> 00:15:04,159 is Cisco has the Cisco assay devices, 441 00:15:04,160 --> 00:15:06,259 these Cisco firewalls, and they 442 00:15:06,260 --> 00:15:08,239 want to be able to inspect the mail that 443 00:15:08,240 --> 00:15:09,769 goes through the devices. 444 00:15:09,770 --> 00:15:11,779 And they are looking for maybe injection 445 00:15:11,780 --> 00:15:13,879 commands they're looking for maybe 446 00:15:13,880 --> 00:15:15,109 they're looking for spam. 447 00:15:15,110 --> 00:15:16,639 But the only way that they think they can 448 00:15:16,640 --> 00:15:18,019 do this is if they have access to the 449 00:15:18,020 --> 00:15:19,219 clear text email. 450 00:15:19,220 --> 00:15:20,989 So what they do is they corrupt any start 451 00:15:20,990 --> 00:15:22,819 to connection that goes through the Cisco 452 00:15:22,820 --> 00:15:24,959 device and then they full access 453 00:15:24,960 --> 00:15:25,960 to the clear text email. 454 00:15:26,930 --> 00:15:28,669 Now, of course, the downfall is every 455 00:15:28,670 --> 00:15:30,289 email that comes out of your nation now 456 00:15:30,290 --> 00:15:31,759 is sent in the clear. 457 00:15:32,930 --> 00:15:34,849 And this isn't really explained in the 458 00:15:34,850 --> 00:15:36,829 Cisco documentation that there's this 459 00:15:36,830 --> 00:15:37,909 giant downfall. 460 00:15:37,910 --> 00:15:40,129 But all your email is now in the clear if 461 00:15:40,130 --> 00:15:42,229 you decide to look for spam. 462 00:15:42,230 --> 00:15:43,609 And of course, there are better solutions 463 00:15:43,610 --> 00:15:45,799 to this, the Cisco Box could 464 00:15:45,800 --> 00:15:48,109 very well terminate the to 465 00:15:48,110 --> 00:15:48,589 connection. 466 00:15:48,590 --> 00:15:50,149 And then we continue with the server and 467 00:15:50,150 --> 00:15:52,399 you can still you start to last and 468 00:15:52,400 --> 00:15:53,989 maybe it's not end to end, but at least 469 00:15:53,990 --> 00:15:55,099 you won't be sending everything in to 470 00:15:55,100 --> 00:15:56,100 clear. 471 00:15:57,530 --> 00:15:59,599 Now, the second way that you could also 472 00:15:59,600 --> 00:16:01,729 do this attack would just be to lie 473 00:16:01,730 --> 00:16:03,259 about what the mail servers are. 474 00:16:04,280 --> 00:16:06,349 So when I go to do my DNS lookup, 475 00:16:06,350 --> 00:16:08,149 I ask, what are the next records for the 476 00:16:08,150 --> 00:16:10,219 server? Was the IP address for 477 00:16:10,220 --> 00:16:11,239 this mail server? 478 00:16:11,240 --> 00:16:13,189 And because we know that no mail servers 479 00:16:13,190 --> 00:16:15,259 ever validate the answers, 480 00:16:15,260 --> 00:16:16,759 no. Those servers actually look at the 481 00:16:16,760 --> 00:16:18,469 certificates to see our man talking to 482 00:16:18,470 --> 00:16:19,429 the right mail server. 483 00:16:19,430 --> 00:16:20,689 There's nothing that actually prevents 484 00:16:20,690 --> 00:16:22,759 the DNS or from just lying and saying, 485 00:16:22,760 --> 00:16:25,039 oh, the mail server, Google dot com 486 00:16:25,040 --> 00:16:27,169 is actually to this IP address and they 487 00:16:27,170 --> 00:16:28,969 own that IP address and all the email. 488 00:16:28,970 --> 00:16:30,469 All of a sudden they can redirect all the 489 00:16:30,470 --> 00:16:32,419 email through that host and then they'll 490 00:16:32,420 --> 00:16:34,189 eventually forwarded onto Gmail so that 491 00:16:34,190 --> 00:16:35,539 no one notices that the email went 492 00:16:35,540 --> 00:16:37,459 missing. But in the meantime, they've had 493 00:16:37,460 --> 00:16:39,140 access to all of the email content. 494 00:16:43,770 --> 00:16:45,089 So we again looked for this by 495 00:16:45,090 --> 00:16:47,129 essentially doing Internet wide scans for 496 00:16:47,130 --> 00:16:49,229 DNS servers and we did these IPV 497 00:16:49,230 --> 00:16:51,419 for scans, we asked every open 498 00:16:51,420 --> 00:16:53,369 resolver on the Internet, what is the 499 00:16:53,370 --> 00:16:55,469 next record and what is the IP address 500 00:16:55,470 --> 00:16:57,389 for the mail servers, for Gmail dot com? 501 00:16:58,440 --> 00:17:00,989 And we saw in hundreds 502 00:17:00,990 --> 00:17:03,629 of Azis and sixty nine countries 503 00:17:04,710 --> 00:17:07,108 falsified responses to what the answers 504 00:17:07,109 --> 00:17:09,299 were. And when we go back, we see that 505 00:17:09,300 --> 00:17:11,189 there's a small fraction for all 506 00:17:11,190 --> 00:17:13,019 countries with about one out of every ten 507 00:17:13,020 --> 00:17:15,209 thousand pieces of mail 508 00:17:15,210 --> 00:17:17,098 that come to Gmail are from one of these 509 00:17:17,099 --> 00:17:19,858 IP addresses that's been falsified. 510 00:17:19,859 --> 00:17:22,108 But at the same time, this 511 00:17:22,109 --> 00:17:24,189 is kind of this is a minimal, 512 00:17:24,190 --> 00:17:26,368 lower, lower bound open 513 00:17:26,369 --> 00:17:28,289 DNS resolvers aren't supposed to be out 514 00:17:28,290 --> 00:17:30,659 there. They're only really being exposed 515 00:17:30,660 --> 00:17:32,309 inadvertently. And we can see that it's 516 00:17:32,310 --> 00:17:33,479 happening. 517 00:17:33,480 --> 00:17:35,009 But we don't necessarily know how much 518 00:17:35,010 --> 00:17:36,449 it's happening because we only see this 519 00:17:36,450 --> 00:17:38,609 glimpse of the mis configured hopes 520 00:17:38,610 --> 00:17:39,599 of hosts. 521 00:17:39,600 --> 00:17:41,369 But we do see that it is happening. 522 00:17:43,410 --> 00:17:45,539 So the state of of delivering 523 00:17:45,540 --> 00:17:47,420 security is rather dismal, 524 00:17:48,510 --> 00:17:50,189 we have start to last, but at the end of 525 00:17:50,190 --> 00:17:51,419 the day, it's just protecting against 526 00:17:51,420 --> 00:17:53,279 these passive connection against passive 527 00:17:53,280 --> 00:17:54,209 eavesdropper. 528 00:17:54,210 --> 00:17:56,339 We know that active attackers are 529 00:17:56,340 --> 00:17:58,019 able to corrupt connections and we know 530 00:17:58,020 --> 00:17:59,819 that active attackers are corrupting 531 00:17:59,820 --> 00:18:00,820 connections. 532 00:18:02,130 --> 00:18:03,869 So what about authenticating mail, 533 00:18:05,340 --> 00:18:07,409 so authenticating mail has had a lot 534 00:18:07,410 --> 00:18:09,029 more attention to it, and that's because 535 00:18:09,030 --> 00:18:11,129 we essentially want to prevent spam. 536 00:18:11,130 --> 00:18:12,599 And so there have been several different 537 00:18:12,600 --> 00:18:14,819 protocols that have been put out 538 00:18:14,820 --> 00:18:17,009 by mail providers that essentially allow 539 00:18:17,010 --> 00:18:18,539 a mail provider when they receive a 540 00:18:18,540 --> 00:18:20,519 message to try to determine if it was 541 00:18:20,520 --> 00:18:22,319 sent from the correct sender. 542 00:18:22,320 --> 00:18:23,909 Was it sent from someone that was 543 00:18:23,910 --> 00:18:25,979 authorized to send from the 544 00:18:25,980 --> 00:18:26,980 source domain? 545 00:18:28,980 --> 00:18:30,750 And this is help essentially 546 00:18:31,860 --> 00:18:34,229 help us along the way in detecting spam, 547 00:18:34,230 --> 00:18:35,489 and there have been three different 548 00:18:35,490 --> 00:18:37,619 protocols that are essentially in 549 00:18:37,620 --> 00:18:39,869 common use today, SPF 550 00:18:39,870 --> 00:18:41,999 Deakin in Denmark, and I'll walk through 551 00:18:42,000 --> 00:18:43,109 each of them. 552 00:18:43,110 --> 00:18:45,209 So SPF is the simplest 553 00:18:45,210 --> 00:18:47,969 of the three, and it essentially allows 554 00:18:47,970 --> 00:18:50,039 a domain to put out a DNS text 555 00:18:50,040 --> 00:18:52,109 record that essentially lists the 556 00:18:52,110 --> 00:18:54,259 IP address or networks that are 557 00:18:54,260 --> 00:18:56,429 allowed to set me send a mail for 558 00:18:56,430 --> 00:18:57,119 it. 559 00:18:57,120 --> 00:18:59,159 So essentially, Gmail says these are the 560 00:18:59,160 --> 00:19:01,409 IP addresses that I owned that I control 561 00:19:01,410 --> 00:19:03,599 of either the IP addresses of my SMTP 562 00:19:03,600 --> 00:19:05,759 servers. Anything sent as me 563 00:19:05,760 --> 00:19:07,919 from other ISPs is not me. 564 00:19:07,920 --> 00:19:09,359 And you can reject it. So you can set a 565 00:19:09,360 --> 00:19:11,549 policy of do I want a soft 566 00:19:11,550 --> 00:19:12,449 rejected meaning? 567 00:19:12,450 --> 00:19:14,189 Probably the mail provider will put it in 568 00:19:14,190 --> 00:19:16,769 the spam folder or take other action, 569 00:19:16,770 --> 00:19:18,569 or do I just delete it off hand? 570 00:19:18,570 --> 00:19:20,279 What do you want me to do as well? 571 00:19:20,280 --> 00:19:22,439 You can delegate records out and say, I'm 572 00:19:22,440 --> 00:19:24,419 letting all my email be hosted by Gmail. 573 00:19:24,420 --> 00:19:26,579 I will just defer my answer 574 00:19:26,580 --> 00:19:28,589 to Gmail and it handles the real world 575 00:19:28,590 --> 00:19:30,539 cases fairly well. 576 00:19:30,540 --> 00:19:32,729 And so in order Stepien gets a message, 577 00:19:32,730 --> 00:19:34,859 it looks up the IP address that 578 00:19:34,860 --> 00:19:37,259 receives mail from and it checks 579 00:19:37,260 --> 00:19:39,479 if it was sent from the host 580 00:19:39,480 --> 00:19:41,429 and then it makes the decision what to 581 00:19:41,430 --> 00:19:42,389 do. 582 00:19:42,390 --> 00:19:44,459 Now, for the most part, 583 00:19:44,460 --> 00:19:46,409 people aren't strictly just rejecting 584 00:19:46,410 --> 00:19:48,059 mail. They're essentially using this as 585 00:19:48,060 --> 00:19:49,709 another indicator within their spam 586 00:19:49,710 --> 00:19:52,199 filters of might this have been spam? 587 00:19:52,200 --> 00:19:53,939 And that's because there are legitimate 588 00:19:53,940 --> 00:19:55,559 reasons that email gets forwarded at 589 00:19:55,560 --> 00:19:56,699 times. 590 00:19:56,700 --> 00:19:57,989 For example, this happens to me 591 00:19:57,990 --> 00:20:00,059 personally. I have an email address at 592 00:20:00,060 --> 00:20:01,919 my university which gets forwarded to my 593 00:20:01,920 --> 00:20:03,299 Gmail account. 594 00:20:03,300 --> 00:20:05,489 If Gmail had or if 595 00:20:05,490 --> 00:20:07,799 domains had a strict policy, all 596 00:20:07,800 --> 00:20:09,059 that email would be thrown away. 597 00:20:10,770 --> 00:20:12,389 So there are reasons that people don't do 598 00:20:12,390 --> 00:20:14,579 strict policies, but it is 599 00:20:14,580 --> 00:20:15,719 out there in some cases. 600 00:20:17,560 --> 00:20:19,759 The next one is d'Yquem, our domain 601 00:20:19,760 --> 00:20:22,179 keys identified mail, and in essence, 602 00:20:22,180 --> 00:20:24,279 what this allows provider to 603 00:20:24,280 --> 00:20:26,229 do is to publish a public key again in 604 00:20:26,230 --> 00:20:28,479 the DNS record that says expect 605 00:20:28,480 --> 00:20:30,939 any email that comes for me to be signed 606 00:20:30,940 --> 00:20:32,889 with this, the private key associated 607 00:20:32,890 --> 00:20:35,019 with this public key, and throw away any 608 00:20:35,020 --> 00:20:36,819 messages where the signature of the 609 00:20:36,820 --> 00:20:39,369 message doesn't match the message. 610 00:20:39,370 --> 00:20:41,469 And so essentially, when the sender sends 611 00:20:41,470 --> 00:20:43,599 mail, attaches, this signature has 612 00:20:43,600 --> 00:20:45,549 an additional header in the message and 613 00:20:45,550 --> 00:20:46,720 it essentially says, 614 00:20:48,070 --> 00:20:49,989 these are the headers, I am taking a half 615 00:20:49,990 --> 00:20:51,909 shove and this is the the hash of the 616 00:20:51,910 --> 00:20:53,169 body. 617 00:20:53,170 --> 00:20:54,789 This is the type of key. 618 00:20:54,790 --> 00:20:56,529 And then the recipient receives the 619 00:20:56,530 --> 00:20:58,659 message. They go and they look up the key 620 00:20:58,660 --> 00:21:00,759 and they check if it was signed, if the 621 00:21:00,760 --> 00:21:01,760 signature matches. 622 00:21:03,400 --> 00:21:05,469 But there's this peculiarity 623 00:21:05,470 --> 00:21:07,629 in this protocol where it's 624 00:21:07,630 --> 00:21:09,789 not obvious where the key is going to be 625 00:21:09,790 --> 00:21:11,949 located for the domain. 626 00:21:11,950 --> 00:21:14,259 I can't go to Gmail dot com to say 627 00:21:14,260 --> 00:21:16,509 what is your d'Yquem public key 628 00:21:16,510 --> 00:21:18,009 off hand instead? 629 00:21:18,010 --> 00:21:19,749 That's actually included in the message 630 00:21:19,750 --> 00:21:21,699 itself and it can actually be different 631 00:21:21,700 --> 00:21:22,700 for every message. 632 00:21:24,490 --> 00:21:26,709 So there's this downfall that because 633 00:21:26,710 --> 00:21:28,659 of this, you have no way of knowing if a 634 00:21:28,660 --> 00:21:30,819 domain is going to sign the mail they 635 00:21:30,820 --> 00:21:32,919 send or not, you can get a message 636 00:21:32,920 --> 00:21:34,959 and know that the signature is invalid. 637 00:21:34,960 --> 00:21:36,609 But if you just take the signature off 638 00:21:36,610 --> 00:21:38,409 all the way, if you just remove the 639 00:21:38,410 --> 00:21:40,659 header, there's no way for the recipient 640 00:21:40,660 --> 00:21:42,849 to actually detect whether the message 641 00:21:42,850 --> 00:21:44,409 should have been signed because there 642 00:21:44,410 --> 00:21:46,479 isn't any canonical place to go look for 643 00:21:46,480 --> 00:21:48,009 this configuration or to look for this 644 00:21:48,010 --> 00:21:49,010 key. 645 00:21:49,480 --> 00:21:50,980 So we deployed d'Yquem, 646 00:21:52,120 --> 00:21:54,339 but it has this fatal and 647 00:21:54,340 --> 00:21:56,619 rather obvious flaw in it, which 648 00:21:56,620 --> 00:21:58,209 is any attack or just removes the 649 00:21:58,210 --> 00:21:59,730 signature in the mail is delivered 650 00:22:00,820 --> 00:22:02,529 and some of the big mail providers kind 651 00:22:02,530 --> 00:22:04,839 of got around this by caching 652 00:22:04,840 --> 00:22:06,009 the different responses. 653 00:22:06,010 --> 00:22:07,479 They know everything that comes from 654 00:22:07,480 --> 00:22:09,639 Yahoo! Before has had 655 00:22:09,640 --> 00:22:12,429 this this header has this signature. 656 00:22:12,430 --> 00:22:14,199 This message probably should have as 657 00:22:14,200 --> 00:22:16,329 well. But it was a pretty wishy 658 00:22:16,330 --> 00:22:17,979 washy kind of configuration. 659 00:22:19,150 --> 00:22:21,369 And so a few years later, 660 00:22:21,370 --> 00:22:23,769 Demarked was released and DMARC 661 00:22:23,770 --> 00:22:26,049 essentially works with both SPF 662 00:22:26,050 --> 00:22:29,019 and Kim and it essentially allows 663 00:22:29,020 --> 00:22:31,449 the sender to publish a policy. 664 00:22:31,450 --> 00:22:33,459 It's allowed just put out this DNS record 665 00:22:33,460 --> 00:22:35,529 that says expect every message 666 00:22:35,530 --> 00:22:37,749 sent to me, sent from me to have 667 00:22:37,750 --> 00:22:39,249 a signature attached. 668 00:22:39,250 --> 00:22:40,989 And if there's no signature attached, 669 00:22:40,990 --> 00:22:42,459 then you can discard it. 670 00:22:42,460 --> 00:22:44,649 And it probably 671 00:22:44,650 --> 00:22:46,629 should have been originally published 672 00:22:46,630 --> 00:22:48,549 with Kim when it originally came out. 673 00:22:48,550 --> 00:22:50,349 But it did not it didn't come out until 674 00:22:50,350 --> 00:22:52,239 about I think it was formally published 675 00:22:52,240 --> 00:22:54,369 within the last couple of years. 676 00:22:54,370 --> 00:22:56,199 So then a recipient checks the policy 677 00:22:56,200 --> 00:22:58,059 when it receives the message and it seems 678 00:22:58,060 --> 00:23:00,189 to either match the SPF record or 679 00:23:00,190 --> 00:23:01,179 the Deakin record. 680 00:23:01,180 --> 00:23:02,859 And for most parts, if you have one or 681 00:23:02,860 --> 00:23:04,399 the other is correct, then the recipient 682 00:23:04,400 --> 00:23:05,400 will accept the message. 683 00:23:07,580 --> 00:23:09,289 From Jamal's perspective, this is going 684 00:23:09,290 --> 00:23:11,509 rather well over 685 00:23:11,510 --> 00:23:14,299 90 percent of email is actually 686 00:23:14,300 --> 00:23:16,759 authenticated with either 687 00:23:16,760 --> 00:23:19,009 SPF or a combination 688 00:23:19,010 --> 00:23:21,319 of both their very few messages 689 00:23:21,320 --> 00:23:23,419 that come through that don't have one 690 00:23:23,420 --> 00:23:25,489 of these headers attached 691 00:23:25,490 --> 00:23:28,099 or aren't from an allowed IP address. 692 00:23:28,100 --> 00:23:30,679 But this is very much dominated 693 00:23:30,680 --> 00:23:32,809 by a small number of very 694 00:23:32,810 --> 00:23:34,729 large providers. 695 00:23:34,730 --> 00:23:36,079 When you go and you look at the top 696 00:23:36,080 --> 00:23:37,579 million domains you see and actually a 697 00:23:37,580 --> 00:23:39,679 very different picture, 698 00:23:39,680 --> 00:23:42,139 less than 50 percent domains have any SPF 699 00:23:42,140 --> 00:23:44,209 policy defined and only about one 700 00:23:44,210 --> 00:23:46,579 percent of domains have a demarked policy 701 00:23:46,580 --> 00:23:47,580 at all. 702 00:23:49,860 --> 00:23:52,319 Of those demarked policies, 703 00:23:52,320 --> 00:23:54,119 only 20 percent actually say you should 704 00:23:54,120 --> 00:23:56,819 reject a message that doesn't match 705 00:23:56,820 --> 00:23:59,609 either the SPF or the decamps signature. 706 00:23:59,610 --> 00:24:01,599 And for most of them, West says none. 707 00:24:01,600 --> 00:24:03,839 What happens is that these 708 00:24:03,840 --> 00:24:05,249 messages are essentially 709 00:24:06,720 --> 00:24:07,799 returned to the sender. 710 00:24:07,800 --> 00:24:09,539 They're they're told back to the center 711 00:24:09,540 --> 00:24:12,239 that we receive this invalid message 712 00:24:12,240 --> 00:24:14,039 and you should know about it. 713 00:24:14,040 --> 00:24:15,659 And so essentially, it's a policy for 714 00:24:15,660 --> 00:24:18,149 reporting, but very, very few people 715 00:24:18,150 --> 00:24:20,430 actually use these in real life. 716 00:24:21,480 --> 00:24:22,559 And that's just because the mail 717 00:24:22,560 --> 00:24:25,439 ecosystem is so complicated. 718 00:24:25,440 --> 00:24:27,599 Very few people use them because 719 00:24:27,600 --> 00:24:29,859 sometimes signatures of messages change. 720 00:24:29,860 --> 00:24:31,529 In fact, any time you send a message 721 00:24:31,530 --> 00:24:32,729 through a mailing list, you get that 722 00:24:32,730 --> 00:24:34,919 little footer at the bottom says 723 00:24:34,920 --> 00:24:36,449 this was sent through this mailing group. 724 00:24:36,450 --> 00:24:39,179 Click on this link to unsubscribe. 725 00:24:39,180 --> 00:24:40,439 When that happens, the message is 726 00:24:40,440 --> 00:24:42,449 altered. The deacon's signature no longer 727 00:24:42,450 --> 00:24:43,559 matches. 728 00:24:43,560 --> 00:24:44,939 And because of this, if you have a 729 00:24:44,940 --> 00:24:47,219 district policy, all and 730 00:24:47,220 --> 00:24:48,899 no one in your organization can use a 731 00:24:48,900 --> 00:24:49,900 mailing list. 732 00:24:51,200 --> 00:24:53,329 For SPF, maybe your emails for 733 00:24:53,330 --> 00:24:55,009 it is through someone else, maybe it uses 734 00:24:55,010 --> 00:24:57,319 a mailing list again 735 00:24:57,320 --> 00:24:58,729 at the end of the day that emails 736 00:24:58,730 --> 00:25:00,259 rejected and we very much have this 737 00:25:00,260 --> 00:25:01,729 mantra that email should always go 738 00:25:01,730 --> 00:25:04,069 through. We aren't willing to just lose 739 00:25:04,070 --> 00:25:06,139 email. And so all of these policies 740 00:25:06,140 --> 00:25:08,269 have ended up being soft fails. 741 00:25:08,270 --> 00:25:10,339 What happens is messages get marked 742 00:25:10,340 --> 00:25:12,709 by spam filters and these go into 743 00:25:12,710 --> 00:25:15,109 being another essentially 744 00:25:15,110 --> 00:25:16,939 another parameter or another variable 745 00:25:16,940 --> 00:25:19,789 that's calculated to determine whether 746 00:25:19,790 --> 00:25:21,859 the spam score for this message is too 747 00:25:21,860 --> 00:25:23,959 high and slowly. 748 00:25:23,960 --> 00:25:26,149 In the last year or so, people started to 749 00:25:26,150 --> 00:25:27,569 use reject policies. 750 00:25:27,570 --> 00:25:29,510 They're still very, very few overall. 751 00:25:34,660 --> 00:25:36,819 So what do we do moving 752 00:25:36,820 --> 00:25:38,379 going forward? 753 00:25:38,380 --> 00:25:40,809 We're kind of in a dismal place today, 754 00:25:40,810 --> 00:25:42,639 start to doesn't really do what we want 755 00:25:42,640 --> 00:25:43,989 it to do. We probably want to know are 756 00:25:43,990 --> 00:25:45,879 talking to the right mail server. 757 00:25:45,880 --> 00:25:47,649 We probably want more people to be using 758 00:25:47,650 --> 00:25:49,389 these signatures and actually validating 759 00:25:49,390 --> 00:25:52,419 messages are what they say they were. 760 00:25:52,420 --> 00:25:55,359 There are two proposals essentially 761 00:25:55,360 --> 00:25:57,159 in and around the ATF right now. 762 00:25:57,160 --> 00:25:59,559 One of them is some strict transport 763 00:25:59,560 --> 00:26:00,560 security. 764 00:26:02,080 --> 00:26:04,629 And this essentially is along the lines 765 00:26:04,630 --> 00:26:07,089 of Høst phrase https. 766 00:26:07,090 --> 00:26:09,339 It allows a domain to say, look, all 767 00:26:09,340 --> 00:26:11,439 the messages that you send to me need 768 00:26:11,440 --> 00:26:12,939 to be encrypted and they need to be 769 00:26:12,940 --> 00:26:14,709 encrypted to this public key. 770 00:26:14,710 --> 00:26:16,539 And I don't want you to deliver any mail 771 00:26:16,540 --> 00:26:18,549 to me unless it's encrypted with that 772 00:26:18,550 --> 00:26:19,749 key. 773 00:26:19,750 --> 00:26:21,339 And for the first time now, you can 774 00:26:21,340 --> 00:26:23,079 actually be fairly certain if you have 775 00:26:23,080 --> 00:26:24,069 the right public key, that you're 776 00:26:24,070 --> 00:26:25,359 actually sending it to the right 777 00:26:25,360 --> 00:26:26,360 destination. 778 00:26:27,490 --> 00:26:28,839 And essentially, the way this is done is 779 00:26:28,840 --> 00:26:30,429 there's a DNS record that's published 780 00:26:30,430 --> 00:26:32,499 that says this is the key that 781 00:26:32,500 --> 00:26:35,889 you should use. For me, it's not perfect. 782 00:26:35,890 --> 00:26:37,749 There is a chance that DNS record could 783 00:26:37,750 --> 00:26:39,939 be forged, but it's a big step 784 00:26:39,940 --> 00:26:42,010 forward compared to where we were today. 785 00:26:43,390 --> 00:26:44,829 As a replacement to Dickin. 786 00:26:44,830 --> 00:26:46,209 There's a proposal called Arcaro 787 00:26:46,210 --> 00:26:48,099 Authenticated received chain, which 788 00:26:48,100 --> 00:26:50,049 essentially helps the process when 789 00:26:50,050 --> 00:26:52,329 messages are altered, maybe we can have 790 00:26:52,330 --> 00:26:53,329 multiple signatures. 791 00:26:53,330 --> 00:26:55,239 We had the signature before this photo 792 00:26:55,240 --> 00:26:57,069 was attached and maybe we add a different 793 00:26:57,070 --> 00:26:58,539 hash when the photo was attached to a 794 00:26:58,540 --> 00:27:00,549 trusted because it comes from a mailing 795 00:27:00,550 --> 00:27:02,139 list provider that we trust. 796 00:27:02,140 --> 00:27:03,339 So we essentially add a little bit more 797 00:27:03,340 --> 00:27:05,679 complexity, a little bit more flexibility 798 00:27:05,680 --> 00:27:07,299 to actually work with the real world. 799 00:27:09,450 --> 00:27:11,669 These are still very much being 800 00:27:11,670 --> 00:27:13,289 figured out, they're being deployed in 801 00:27:13,290 --> 00:27:15,749 practice very slowly because 802 00:27:15,750 --> 00:27:17,039 it's very hard to troubleshoot and 803 00:27:17,040 --> 00:27:19,319 messages disappear 804 00:27:19,320 --> 00:27:20,789 to track progress. 805 00:27:20,790 --> 00:27:23,159 Google is publishing a transparency 806 00:27:23,160 --> 00:27:26,339 report that displays 807 00:27:26,340 --> 00:27:28,439 from the day prior the amount 808 00:27:28,440 --> 00:27:30,179 of email in and out of Gmail that was 809 00:27:30,180 --> 00:27:32,399 encrypted, as well as how much email 810 00:27:32,400 --> 00:27:34,679 to each of the major providers was 811 00:27:34,680 --> 00:27:35,999 encrypted as well. 812 00:27:36,000 --> 00:27:38,219 Within the census project, we have 813 00:27:38,220 --> 00:27:41,009 launched a dashboard of the top servers 814 00:27:41,010 --> 00:27:43,379 that are no longer deployed start to less 815 00:27:43,380 --> 00:27:45,329 or that we're observing this start to 816 00:27:45,330 --> 00:27:46,329 less shipping behavior. 817 00:27:46,330 --> 00:27:47,909 We're seeing these text messages being 818 00:27:47,910 --> 00:27:49,979 corrupted and so we can hopefully track 819 00:27:49,980 --> 00:27:51,899 over time to see where the popular 820 00:27:51,900 --> 00:27:53,789 domains we need to go and harass to 821 00:27:53,790 --> 00:27:55,829 actually go in and start to less on their 822 00:27:55,830 --> 00:27:56,830 servers. 823 00:27:58,940 --> 00:28:00,649 So in conclusion, the mill community has 824 00:28:00,650 --> 00:28:02,359 started to deploy these new security 825 00:28:02,360 --> 00:28:04,399 extensions, but I think we can all agree 826 00:28:04,400 --> 00:28:05,839 we're not near the place where we want to 827 00:28:05,840 --> 00:28:06,739 be. 828 00:28:06,740 --> 00:28:08,299 We still don't have authentication. 829 00:28:08,300 --> 00:28:09,919 We still have no protection against any 830 00:28:09,920 --> 00:28:11,029 active attacks. 831 00:28:11,030 --> 00:28:12,529 And there are attacks currently happening 832 00:28:12,530 --> 00:28:14,689 against the passive type of protection 833 00:28:14,690 --> 00:28:16,969 we have, unfortunately, until 834 00:28:16,970 --> 00:28:19,259 there's this near pervasive deployment. 835 00:28:19,260 --> 00:28:21,109 It's unlikely that adopters will require 836 00:28:21,110 --> 00:28:23,209 encryption when you only have seventy 837 00:28:23,210 --> 00:28:24,769 five percent of domains on the Internet, 838 00:28:24,770 --> 00:28:26,389 you're not going to say I'm not going to 839 00:28:26,390 --> 00:28:28,339 send it to the other 25 percent because 840 00:28:28,340 --> 00:28:29,509 they don't have encryption. That's just 841 00:28:29,510 --> 00:28:30,979 not going to happen in the real world as 842 00:28:30,980 --> 00:28:32,809 much as we want it to. 843 00:28:32,810 --> 00:28:35,359 Gmail is currently working 844 00:28:35,360 --> 00:28:37,159 and discussing the possibility of showing 845 00:28:37,160 --> 00:28:39,139 indicators of whether a message was sent 846 00:28:39,140 --> 00:28:41,209 securely or not in hopes that they can 847 00:28:41,210 --> 00:28:43,459 start to pressure organizations into 848 00:28:43,460 --> 00:28:44,779 deploying start tools. 849 00:28:44,780 --> 00:28:45,780 We'll see where that goes. 850 00:28:47,300 --> 00:28:49,669 There are several proposals kind 851 00:28:49,670 --> 00:28:51,739 of in the works, both Arc 852 00:28:51,740 --> 00:28:53,569 Astra Transport Security, which should 853 00:28:53,570 --> 00:28:56,239 help Ettalong what's currently in place. 854 00:28:56,240 --> 00:28:57,949 But at the end of the day, we still have 855 00:28:57,950 --> 00:28:59,240 a lot of work that needs to be done. 856 00:29:01,630 --> 00:29:02,630 Questions. 857 00:29:14,020 --> 00:29:16,149 As always, for the 858 00:29:16,150 --> 00:29:17,979 questions, just line up at the 859 00:29:17,980 --> 00:29:20,049 microphones, I will call you when 860 00:29:20,050 --> 00:29:21,039 you can ask your question. 861 00:29:21,040 --> 00:29:23,619 If you're on the stream, go on AFSC, 862 00:29:23,620 --> 00:29:25,959 go on Twitter and ask 863 00:29:25,960 --> 00:29:27,699 Rosignol Angel. 864 00:29:27,700 --> 00:29:29,619 And if you need somebody to bring a 865 00:29:29,620 --> 00:29:31,389 microphone to you, please raise your 866 00:29:31,390 --> 00:29:32,469 hands. 867 00:29:32,470 --> 00:29:34,390 And then that will probably happen to. 868 00:29:36,010 --> 00:29:37,929 Let's start on microphone two. 869 00:29:37,930 --> 00:29:39,579 Oh, hello for us. 870 00:29:39,580 --> 00:29:41,259 Thanks for the very nice overview of the 871 00:29:41,260 --> 00:29:43,359 current state, especially as viewed from 872 00:29:43,360 --> 00:29:45,279 the other side of these insights from 873 00:29:45,280 --> 00:29:47,529 Gmail are really very interesting in 874 00:29:47,530 --> 00:29:49,779 Germany as quite a lobby for using 875 00:29:49,780 --> 00:29:51,639 the NSA to solve some of these problems. 876 00:29:51,640 --> 00:29:53,979 And there are already standards like 877 00:29:53,980 --> 00:29:55,959 DAINE and everything to do things similar 878 00:29:55,960 --> 00:29:58,149 to your SMTP Stockdale's. 879 00:29:58,150 --> 00:29:59,349 You didn't mention that at all. 880 00:29:59,350 --> 00:30:01,089 So what do you think about those options? 881 00:30:01,090 --> 00:30:03,429 So Dean is a possibility. 882 00:30:03,430 --> 00:30:05,399 It could be used as essentially a public 883 00:30:05,400 --> 00:30:06,400 key. 884 00:30:07,640 --> 00:30:09,409 I think a lot of people don't believe 885 00:30:09,410 --> 00:30:11,659 that the NSA is going to be deployed 886 00:30:11,660 --> 00:30:13,219 in the real world. That's the right 887 00:30:13,220 --> 00:30:15,199 solution. I think it's on the right path 888 00:30:15,200 --> 00:30:16,969 to getting something out. 889 00:30:16,970 --> 00:30:19,279 But there's still very, very few domains 890 00:30:19,280 --> 00:30:21,259 that use DNS is less than one percent 891 00:30:21,260 --> 00:30:23,419 currently. And what we need is 892 00:30:23,420 --> 00:30:24,709 a solution that works today. 893 00:30:24,710 --> 00:30:26,119 That's something that can be deployed 894 00:30:27,440 --> 00:30:29,069 little by little and something like 895 00:30:29,070 --> 00:30:31,069 stress transfer security allows us along 896 00:30:31,070 --> 00:30:32,299 the way while we figure out what a more 897 00:30:32,300 --> 00:30:33,350 long term solution is. 898 00:30:35,640 --> 00:30:37,799 They can, Zainal Angel, 899 00:30:37,800 --> 00:30:38,429 please. 900 00:30:38,430 --> 00:30:39,959 I had exactly the same question. 901 00:30:39,960 --> 00:30:40,960 Thank you. 902 00:30:41,550 --> 00:30:44,429 OK. And then microphone four, please. 903 00:30:44,430 --> 00:30:46,889 Um, yeah. About the state's 904 00:30:46,890 --> 00:30:47,779 proposal. 905 00:30:47,780 --> 00:30:49,949 I'm wondering, why are you using a DNS 906 00:30:49,950 --> 00:30:52,169 channel for it as an insecure channel 907 00:30:52,170 --> 00:30:54,539 instead of doing it like HD 908 00:30:54,540 --> 00:30:57,359 is actually doing it and using the 909 00:30:57,360 --> 00:30:59,639 if you want to have a secure 910 00:30:59,640 --> 00:31:01,619 connection, then inside that already 911 00:31:01,620 --> 00:31:03,779 encrypted channel, transmit 912 00:31:03,780 --> 00:31:06,059 information like, OK, but in the future, 913 00:31:06,060 --> 00:31:08,339 I also want to have encrypted 914 00:31:08,340 --> 00:31:10,259 connection and please stole my 915 00:31:10,260 --> 00:31:11,819 certificate or something like that, 916 00:31:11,820 --> 00:31:13,949 because I think that would be more 917 00:31:13,950 --> 00:31:15,809 secure than you would have a trust on. 918 00:31:15,810 --> 00:31:18,509 First, your security while your proposal. 919 00:31:18,510 --> 00:31:20,609 You're relying basically that the DNS is 920 00:31:20,610 --> 00:31:22,709 not, uh, not 921 00:31:22,710 --> 00:31:24,119 modified. 922 00:31:24,120 --> 00:31:25,529 Yeah, and this is a good point. 923 00:31:25,530 --> 00:31:27,629 And I think in the best of cases, we 924 00:31:27,630 --> 00:31:29,399 would have something along both cases 925 00:31:29,400 --> 00:31:30,689 where either one you trust. 926 00:31:32,550 --> 00:31:34,979 What we've seen is that 927 00:31:34,980 --> 00:31:36,359 essentially these are man, the middle 928 00:31:36,360 --> 00:31:39,479 boxes that have access to the message. 929 00:31:39,480 --> 00:31:41,399 And if they're already placed in start to 930 00:31:41,400 --> 00:31:42,659 last, there's a little reason they can 931 00:31:42,660 --> 00:31:45,519 also replace the other message 932 00:31:45,520 --> 00:31:47,339 or that that would never happen, whereas 933 00:31:47,340 --> 00:31:49,649 DNS has a little bit more roundabout's. 934 00:31:49,650 --> 00:31:51,569 It's a different path. 935 00:31:51,570 --> 00:31:53,189 There's caching in place. 936 00:31:53,190 --> 00:31:54,929 End of the day, you're right, neither are 937 00:31:54,930 --> 00:31:56,160 perfect solutions 938 00:31:57,570 --> 00:31:59,159 and I personally would like to see both 939 00:31:59,160 --> 00:32:00,160 happen. 940 00:32:01,620 --> 00:32:02,849 Number one, please. 941 00:32:04,170 --> 00:32:06,749 Hello, Latymer, the Bromell daughter, you 942 00:32:06,750 --> 00:32:09,449 are in your research with Google, 943 00:32:09,450 --> 00:32:11,639 you count things like 944 00:32:11,640 --> 00:32:14,939 certificate validation and 945 00:32:14,940 --> 00:32:17,729 support or for outdated 946 00:32:17,730 --> 00:32:18,809 ciphers. 947 00:32:18,810 --> 00:32:21,689 But as we know, start lists are 948 00:32:21,690 --> 00:32:23,879 only protects against passive 949 00:32:23,880 --> 00:32:26,549 attacks and actually certificate 950 00:32:26,550 --> 00:32:28,089 validation and nothing. 951 00:32:28,090 --> 00:32:29,400 And so the question is why? 952 00:32:31,160 --> 00:32:33,139 I'm not quite sure if I follow, why are 953 00:32:33,140 --> 00:32:36,079 we not building certificates or 954 00:32:36,080 --> 00:32:38,179 why are we not doing what are 955 00:32:38,180 --> 00:32:40,189 in active? 956 00:32:40,190 --> 00:32:42,619 Because actually accept an invalid 957 00:32:42,620 --> 00:32:45,259 certificate and not checking 958 00:32:45,260 --> 00:32:47,719 for outdated Cy-Fair allows 959 00:32:47,720 --> 00:32:49,730 you to keep a connection and creeped it. 960 00:32:50,900 --> 00:32:51,900 True. 961 00:32:53,740 --> 00:32:55,509 My guess, I don't know if I have a 962 00:32:55,510 --> 00:32:57,369 perfect answer for you, my guess is that 963 00:32:57,370 --> 00:32:59,109 most mail servers will accept just about 964 00:32:59,110 --> 00:33:00,339 anything. 965 00:33:00,340 --> 00:33:01,809 This is because all of them are using 966 00:33:01,810 --> 00:33:03,759 open SSL except for exchange, and they're 967 00:33:03,760 --> 00:33:05,349 kind of following what the open SSL 968 00:33:05,350 --> 00:33:07,059 defaults are. 969 00:33:07,060 --> 00:33:09,579 My guess is that the majority will accept 970 00:33:09,580 --> 00:33:11,409 insecure ciphers, but I don't have 971 00:33:11,410 --> 00:33:12,410 numbers offhand. 972 00:33:14,890 --> 00:33:17,199 Number eight, please. 973 00:33:17,200 --> 00:33:18,200 Yes, hi. 974 00:33:19,510 --> 00:33:21,609 It seems that the big 975 00:33:21,610 --> 00:33:23,499 email providers are more and more moving 976 00:33:23,500 --> 00:33:25,989 towards a gated community approach, 977 00:33:25,990 --> 00:33:28,069 more or less looking 978 00:33:28,070 --> 00:33:30,129 for five or 10 years ahead of 979 00:33:30,130 --> 00:33:32,799 us. Is there any hope for decentralized 980 00:33:32,800 --> 00:33:34,479 e-mail, basically hosting your own email 981 00:33:34,480 --> 00:33:36,279 server or. That's pretty much dead at 982 00:33:36,280 --> 00:33:37,280 this point. 983 00:33:38,200 --> 00:33:40,329 Yeah, this 984 00:33:40,330 --> 00:33:41,289 is a very valid point. 985 00:33:41,290 --> 00:33:42,939 It's becoming more and more complicated 986 00:33:42,940 --> 00:33:45,159 by the day to deploy mail 987 00:33:45,160 --> 00:33:47,769 server correctly and 988 00:33:47,770 --> 00:33:48,770 I. 989 00:33:50,710 --> 00:33:52,539 I have no idea what it will look like, to 990 00:33:52,540 --> 00:33:54,789 be honest, I think we are seeing 991 00:33:54,790 --> 00:33:56,199 more and more people move to cloud 992 00:33:56,200 --> 00:33:57,880 providers because it's easier 993 00:33:58,960 --> 00:34:01,599 if you deploy these technologies. 994 00:34:01,600 --> 00:34:02,679 It's not that any of these are 995 00:34:02,680 --> 00:34:04,059 proprietary. 996 00:34:04,060 --> 00:34:06,339 You can, if you so desire, deploy them. 997 00:34:07,510 --> 00:34:09,638 It's just that it's a pain to 998 00:34:09,639 --> 00:34:11,799 it's a pain to get all of these right. 999 00:34:11,800 --> 00:34:13,178 And that's one of the things that cloud 1000 00:34:13,179 --> 00:34:14,529 providers do give you. 1001 00:34:14,530 --> 00:34:17,349 So I suspect that will continue 1002 00:34:17,350 --> 00:34:18,999 to see more people move to cloud 1003 00:34:19,000 --> 00:34:20,919 providers, but there will be always be 1004 00:34:20,920 --> 00:34:22,539 that handful of organizations that still 1005 00:34:22,540 --> 00:34:23,739 maintain their own mail servers. 1006 00:34:25,300 --> 00:34:27,428 I was going to say 1007 00:34:27,429 --> 00:34:29,829 that even if you deploy everything 1008 00:34:29,830 --> 00:34:31,420 correctly today, like you know 1009 00:34:32,440 --> 00:34:35,499 everything, you still get blacklisted. 1010 00:34:35,500 --> 00:34:37,658 And that's more of the problem, really, 1011 00:34:37,659 --> 00:34:39,638 because it's not a technical issue 1012 00:34:39,639 --> 00:34:41,529 anymore. It's simply the big providers 1013 00:34:41,530 --> 00:34:43,899 don't want to deal with anything 1014 00:34:43,900 --> 00:34:46,209 besides the top 10, and that's it. 1015 00:34:46,210 --> 00:34:47,888 So I don't have much good information on 1016 00:34:47,889 --> 00:34:48,889 that, to be honest. 1017 00:34:50,960 --> 00:34:53,178 Number four, please, 1018 00:34:53,179 --> 00:34:55,879 on a slight moving forward with 1019 00:34:55,880 --> 00:34:59,359 a SMTP, CDS and ARCC, 1020 00:34:59,360 --> 00:35:01,489 maybe I misunderstood it or is slightly 1021 00:35:01,490 --> 00:35:03,889 misleading because as far 1022 00:35:03,890 --> 00:35:06,199 as I understood you were, you were saying 1023 00:35:06,200 --> 00:35:09,019 that HECS offers 1024 00:35:09,020 --> 00:35:11,569 public keep painting, which it does not. 1025 00:35:11,570 --> 00:35:14,449 Or are you saying that 1026 00:35:14,450 --> 00:35:16,729 SMTP CDS offers public 1027 00:35:16,730 --> 00:35:17,929 opinion? 1028 00:35:17,930 --> 00:35:19,999 So I am sure it's similar along 1029 00:35:20,000 --> 00:35:22,159 the lines of HECS or PKP 1030 00:35:22,160 --> 00:35:24,049 along those lines where you can panichi 1031 00:35:24,050 --> 00:35:25,249 your correct HECS. 1032 00:35:25,250 --> 00:35:27,739 HECS is not pinnies specific key, 1033 00:35:27,740 --> 00:35:29,839 but I believe ESTs will be able to 1034 00:35:29,840 --> 00:35:30,499 do that. 1035 00:35:30,500 --> 00:35:32,299 OK, thanks. 1036 00:35:32,300 --> 00:35:34,549 Signal angel, please, isn't 1037 00:35:34,550 --> 00:35:36,709 all the transport layer security 1038 00:35:36,710 --> 00:35:38,929 only one step on the road to 1039 00:35:38,930 --> 00:35:39,930 end to end? 1040 00:35:41,810 --> 00:35:44,629 Yeah, I think in the perfect world 1041 00:35:44,630 --> 00:35:46,459 we would have end to end security. 1042 00:35:46,460 --> 00:35:49,009 Every person here would be using PGP. 1043 00:35:49,010 --> 00:35:51,079 But the reality is it's not that 1044 00:35:51,080 --> 00:35:52,080 easy. 1045 00:35:52,790 --> 00:35:54,379 There's only a minuscule number of people 1046 00:35:54,380 --> 00:35:56,479 that use PGP today. 1047 00:35:56,480 --> 00:35:58,159 There are still some major challenges 1048 00:35:58,160 --> 00:36:00,110 that stay ahead for PGP. 1049 00:36:01,190 --> 00:36:02,959 Big mail providers are still running into 1050 00:36:02,960 --> 00:36:05,029 problems of how do they to detect 1051 00:36:05,030 --> 00:36:06,709 fraudulent messages, how do they catch 1052 00:36:06,710 --> 00:36:08,839 spam even in the case 1053 00:36:08,840 --> 00:36:09,859 of PGP? 1054 00:36:09,860 --> 00:36:11,239 A lot of your metadata is still in the 1055 00:36:11,240 --> 00:36:13,579 clear that if we are sending the mail to 1056 00:36:13,580 --> 00:36:15,379 who you're sending mail from, the subject 1057 00:36:15,380 --> 00:36:16,879 of the message or sent along with this 1058 00:36:16,880 --> 00:36:17,880 encrypted body. 1059 00:36:18,830 --> 00:36:20,659 And so really, I see this as an 1060 00:36:20,660 --> 00:36:22,879 orthogonal issue until 1061 00:36:22,880 --> 00:36:24,949 we have a good solution to end to 1062 00:36:24,950 --> 00:36:26,539 end encryption, which we just don't 1063 00:36:26,540 --> 00:36:28,339 today, and we don't have one in the 1064 00:36:28,340 --> 00:36:30,199 foreseeable future. 1065 00:36:30,200 --> 00:36:32,149 We do need to be essentially looking at 1066 00:36:32,150 --> 00:36:34,459 both of these different sides. 1067 00:36:36,760 --> 00:36:38,649 Number two, please. 1068 00:36:38,650 --> 00:36:40,989 Yes, I was wondering if you were looking 1069 00:36:40,990 --> 00:36:43,269 into the privacy implications of those 1070 00:36:43,270 --> 00:36:45,159 new technologies, like, for example, if 1071 00:36:45,160 --> 00:36:47,899 you have Dekha demarked, deployed 1072 00:36:47,900 --> 00:36:50,199 a small domain and sent 1073 00:36:50,200 --> 00:36:52,959 email to some 1074 00:36:52,960 --> 00:36:55,449 other domain and then get a response 1075 00:36:55,450 --> 00:36:57,679 from from Google and a Deacon 1076 00:36:57,680 --> 00:36:59,859 DeMarco report telling you, OK, 1077 00:36:59,860 --> 00:37:02,229 I got this one e-mail from there. 1078 00:37:02,230 --> 00:37:04,479 So, you know, OK, he's forwarding 1079 00:37:04,480 --> 00:37:05,480 to Gmail. 1080 00:37:06,190 --> 00:37:07,929 So we haven't looked at it, but be a very 1081 00:37:07,930 --> 00:37:09,819 interesting kind of avenue to go down. 1082 00:37:11,920 --> 00:37:14,049 Number one, please, hello, 1083 00:37:14,050 --> 00:37:15,639 coming back to the Senate to pass this 1084 00:37:15,640 --> 00:37:17,199 proposal. I'm the guy with the guitar, to 1085 00:37:17,200 --> 00:37:18,189 be sure. 1086 00:37:18,190 --> 00:37:20,019 I really don't like it. 1087 00:37:20,020 --> 00:37:22,649 The main point is it might be very 1088 00:37:22,650 --> 00:37:24,909 well for large companies 1089 00:37:24,910 --> 00:37:26,739 like Gmail and Yahoo! 1090 00:37:26,740 --> 00:37:28,869 And Comcast and Microsoft, like the Air 1091 00:37:28,870 --> 00:37:31,299 Force, or if you talk to animal 1092 00:37:31,300 --> 00:37:33,099 experts or to small operators, to 1093 00:37:33,100 --> 00:37:35,239 universities, they want they want 1094 00:37:35,240 --> 00:37:37,389 to deploy it because it 1095 00:37:37,390 --> 00:37:39,319 needs out-of-band authentication over 1096 00:37:39,320 --> 00:37:40,689 https anyway. 1097 00:37:40,690 --> 00:37:43,239 So you need to set up a website 1098 00:37:43,240 --> 00:37:45,939 in addition to the MTA and have another 1099 00:37:45,940 --> 00:37:47,379 party communicating with you. 1100 00:37:47,380 --> 00:37:49,599 So, I mean, it's nice for large, large 1101 00:37:49,600 --> 00:37:51,549 hosting providers, but it's not for all 1102 00:37:51,550 --> 00:37:53,289 of the small MTA out there. 1103 00:37:53,290 --> 00:37:54,189 Sure. 1104 00:37:54,190 --> 00:37:55,839 I don't know if you have GitHub issue 1105 00:37:55,840 --> 00:37:56,949 you're referring to offhand, but I can 1106 00:37:56,950 --> 00:37:58,299 answer the question more broadly. 1107 00:38:00,520 --> 00:38:02,919 DNS is already used pretty pervasively 1108 00:38:02,920 --> 00:38:04,569 as what's being used for Demarcates being 1109 00:38:04,570 --> 00:38:06,039 useless for SPF. 1110 00:38:06,040 --> 00:38:07,869 So it's not that people need to really 1111 00:38:07,870 --> 00:38:09,609 deploy new technology. 1112 00:38:09,610 --> 00:38:11,349 There is potential to use new ones. 1113 00:38:11,350 --> 00:38:13,549 And personally, I agree that there should 1114 00:38:13,550 --> 00:38:15,219 there there's no reason we couldn't have 1115 00:38:15,220 --> 00:38:16,239 something along this. 1116 00:38:16,240 --> 00:38:18,459 The way of HBK 1117 00:38:18,460 --> 00:38:20,529 for your server communicates it as well 1118 00:38:20,530 --> 00:38:21,909 as through an out-of-band way 1119 00:38:22,990 --> 00:38:24,129 through DNS. 1120 00:38:24,130 --> 00:38:26,259 So ideally, I would 1121 00:38:26,260 --> 00:38:28,389 like to use something like tech, not 1122 00:38:28,390 --> 00:38:30,849 data in addition to the N.S.A. 1123 00:38:30,850 --> 00:38:33,309 extension that will do something like 1124 00:38:33,310 --> 00:38:35,379 it just as far as to be sure, 1125 00:38:35,380 --> 00:38:37,599 and then have a two year extension like 1126 00:38:37,600 --> 00:38:39,669 tech that has a proper control over 1127 00:38:39,670 --> 00:38:41,079 properties as well. 1128 00:38:41,080 --> 00:38:43,029 I mean, they basically just cache stuff 1129 00:38:43,030 --> 00:38:45,279 and take it off DNS or out 1130 00:38:45,280 --> 00:38:47,499 of a well known euro 1131 00:38:47,500 --> 00:38:49,689 without a penalty location, which 1132 00:38:49,690 --> 00:38:51,069 kind of sucks, in my opinion. 1133 00:38:51,070 --> 00:38:52,359 Yep. There's no perfect solution here 1134 00:38:52,360 --> 00:38:53,139 right now. 1135 00:38:53,140 --> 00:38:54,140 Yeah, I agree. 1136 00:38:55,720 --> 00:38:57,489 Internet plays. 1137 00:38:57,490 --> 00:38:59,379 Maybe it's easier to move all these big 1138 00:38:59,380 --> 00:39:01,539 corporations to secure email handling. 1139 00:39:01,540 --> 00:39:03,159 But another nice thing would be to 1140 00:39:03,160 --> 00:39:05,259 decentralized email servers, 1141 00:39:05,260 --> 00:39:07,359 um, which solves other problems. 1142 00:39:07,360 --> 00:39:08,709 Is there a combined way? 1143 00:39:12,210 --> 00:39:15,119 I think these orthogonal again, 1144 00:39:15,120 --> 00:39:17,369 these technologies are being used by both 1145 00:39:17,370 --> 00:39:19,349 small providers and large, I think what 1146 00:39:19,350 --> 00:39:21,029 we're seeing is that there may not be the 1147 00:39:21,030 --> 00:39:23,129 expertize to do it with small providers, 1148 00:39:23,130 --> 00:39:25,319 that we aren't seeing all the steps, 1149 00:39:25,320 --> 00:39:26,459 but there isn't anything in the 1150 00:39:26,460 --> 00:39:27,460 technology 1151 00:39:28,890 --> 00:39:30,839 itself that would prevent that. 1152 00:39:30,840 --> 00:39:32,369 I think you can debate whether having 1153 00:39:32,370 --> 00:39:34,049 large e-mail providers or small email 1154 00:39:34,050 --> 00:39:35,819 providers are good versus bad, but I 1155 00:39:35,820 --> 00:39:37,529 think it's in a somewhat independent 1156 00:39:37,530 --> 00:39:38,530 argument of this. 1157 00:39:40,330 --> 00:39:42,339 Number two, please. 1158 00:39:42,340 --> 00:39:44,349 OK, as we have some more time left, are 1159 00:39:44,350 --> 00:39:45,459 coming back to you in a sec. 1160 00:39:45,460 --> 00:39:47,439 Again, I understand the argument. 1161 00:39:47,440 --> 00:39:49,329 It's not really used in the wild so far 1162 00:39:49,330 --> 00:39:50,499 by many users. 1163 00:39:50,500 --> 00:39:53,259 But as you already shown in your slides, 1164 00:39:53,260 --> 00:39:55,149 there are a few very big providers 1165 00:39:55,150 --> 00:39:56,979 controlling lots of the e-mail traffic in 1166 00:39:56,980 --> 00:39:57,909 this world. 1167 00:39:57,910 --> 00:40:00,129 So if those that 1168 00:40:00,130 --> 00:40:02,289 the SEC, at least for resolving and for 1169 00:40:02,290 --> 00:40:03,909 publishing the domains, I mean, Google is 1170 00:40:03,910 --> 00:40:06,849 using the Nesic for quite some point, 1171 00:40:06,850 --> 00:40:08,229 at least some of the problems already 1172 00:40:08,230 --> 00:40:09,639 would be solved, like faking a mixed 1173 00:40:09,640 --> 00:40:11,019 record and everything like that. 1174 00:40:11,020 --> 00:40:13,299 And if they employ, then at 1175 00:40:13,300 --> 00:40:15,039 least for their outgoing connections, 1176 00:40:15,040 --> 00:40:16,329 publish records for the incoming 1177 00:40:16,330 --> 00:40:18,309 connections. Lots of traffic in the 1178 00:40:18,310 --> 00:40:20,379 Internet would already be 1179 00:40:20,380 --> 00:40:21,879 solved. From all of the problems you 1180 00:40:21,880 --> 00:40:23,949 mention and thinking far, you would 1181 00:40:23,950 --> 00:40:25,899 have end to end security with things like 1182 00:40:25,900 --> 00:40:28,089 Open PGP, Key Esmay and everything 1183 00:40:28,090 --> 00:40:28,989 like that. 1184 00:40:28,990 --> 00:40:31,099 So wouldn't it be just better to push 1185 00:40:31,100 --> 00:40:32,100 the Intersect more? 1186 00:40:38,190 --> 00:40:40,289 Again, yes, the insect is 1187 00:40:40,290 --> 00:40:42,419 a technical possibility, I haven't 1188 00:40:42,420 --> 00:40:44,849 seen many of the big providers 1189 00:40:44,850 --> 00:40:47,339 use DNS, SEC requires 1190 00:40:47,340 --> 00:40:50,099 all of the clients still support it 1191 00:40:50,100 --> 00:40:52,079 and yes, it technically solves it. 1192 00:40:52,080 --> 00:40:54,119 But I think we are seeing that the SEC is 1193 00:40:54,120 --> 00:40:55,619 played with so many other issues. 1194 00:40:55,620 --> 00:40:57,869 Technically, I think a lot 1195 00:40:57,870 --> 00:40:58,949 of people in the world want to see a 1196 00:40:58,950 --> 00:41:01,319 better solution before they push for 1197 00:41:01,320 --> 00:41:02,489 widespread adoption. 1198 00:41:03,570 --> 00:41:05,939 OK, is there a middle 1199 00:41:05,940 --> 00:41:07,859 large providers in Germany already using 1200 00:41:07,860 --> 00:41:09,359 it and not having really big problems 1201 00:41:09,360 --> 00:41:10,379 with it? 1202 00:41:10,380 --> 00:41:12,539 So, I mean, even if we go 1203 00:41:12,540 --> 00:41:14,819 back and look at key cyesis, 1204 00:41:14,820 --> 00:41:16,219 I think from day one, a lot of people 1205 00:41:16,220 --> 00:41:18,059 will argue that the technology has some 1206 00:41:18,060 --> 00:41:20,189 flaws in it, that people ask the 1207 00:41:20,190 --> 00:41:21,299 question, why is this even worth 1208 00:41:21,300 --> 00:41:23,849 deploying or building a technology 1209 00:41:23,850 --> 00:41:27,179 even on a thousand twenty four RSA keys 1210 00:41:27,180 --> 00:41:28,679 that we know are probably going to be 1211 00:41:28,680 --> 00:41:30,299 insecure in a matter of years, that we're 1212 00:41:30,300 --> 00:41:32,309 pushing for it to be used in the next 1213 00:41:32,310 --> 00:41:34,169 couple of years? There's a question of is 1214 00:41:34,170 --> 00:41:35,369 this the right thing to be putting our 1215 00:41:35,370 --> 00:41:36,629 effort forth again? 1216 00:41:36,630 --> 00:41:38,729 Yes, in an optimal 1217 00:41:38,730 --> 00:41:40,649 world, we would deploy every technology 1218 00:41:40,650 --> 00:41:42,479 solution possible. Everyone would use the 1219 00:41:42,480 --> 00:41:43,889 second. The better solution would come 1220 00:41:43,890 --> 00:41:45,779 out at the end of the day. 1221 00:41:45,780 --> 00:41:47,609 But I think what we need is a better 1222 00:41:47,610 --> 00:41:49,319 solution that everyone can use. 1223 00:41:49,320 --> 00:41:51,119 And I don't think anyone is saying don't 1224 00:41:51,120 --> 00:41:52,499 use DNS. 1225 00:41:52,500 --> 00:41:54,239 Nothing is preventing organizations from 1226 00:41:54,240 --> 00:41:56,549 using it or from verifying it 1227 00:41:56,550 --> 00:41:58,139 is really up to the organization whether 1228 00:41:58,140 --> 00:42:00,539 or not they want to deploy DNS 1229 00:42:00,540 --> 00:42:02,039 for themselves. 1230 00:42:02,040 --> 00:42:04,079 But I think what we've seen is that not a 1231 00:42:04,080 --> 00:42:05,639 lot of people are deploying it. 1232 00:42:05,640 --> 00:42:07,789 And what that says is that 1233 00:42:07,790 --> 00:42:09,659 we need to look at other alternatives 1234 00:42:09,660 --> 00:42:11,639 that might be easier to deploy, but 1235 00:42:11,640 --> 00:42:13,409 possibly also the reasons that people 1236 00:42:13,410 --> 00:42:15,749 like this talk mentioned all the problems 1237 00:42:15,750 --> 00:42:17,909 of the six thousand twenty 1238 00:42:17,910 --> 00:42:19,799 four cases are basically solved in a few 1239 00:42:19,800 --> 00:42:21,039 years. We have new algorithms they 1240 00:42:21,040 --> 00:42:23,249 already deployed, getting shorter keys, 1241 00:42:23,250 --> 00:42:24,809 following suspected sites and everything. 1242 00:42:24,810 --> 00:42:26,459 So the is evolving. 1243 00:42:26,460 --> 00:42:28,629 So I wouldn't keep it off 1244 00:42:28,630 --> 00:42:30,359 and I'd be happy to see that. 1245 00:42:30,360 --> 00:42:31,559 See where that goes. 1246 00:42:31,560 --> 00:42:32,560 OK, thank you. 1247 00:42:34,150 --> 00:42:35,859 Do we have any more questions? 1248 00:42:35,860 --> 00:42:38,319 We have astonishing 1249 00:42:38,320 --> 00:42:40,380 18 minutes left for Q&A. 1250 00:42:42,010 --> 00:42:42,459 Go ahead. 1251 00:42:42,460 --> 00:42:44,559 Number one, yeah, you were mentioning 1252 00:42:44,560 --> 00:42:46,659 that by default, 1253 00:42:46,660 --> 00:42:49,149 a lot of open source 1254 00:42:49,150 --> 00:42:51,309 methods do not and encrypt 1255 00:42:51,310 --> 00:42:53,739 either incoming or outgoing 1256 00:42:53,740 --> 00:42:55,509 mail. Are you participating in mailing 1257 00:42:55,510 --> 00:42:57,999 lists to try to change that policy? 1258 00:42:58,000 --> 00:43:00,159 So I have seen some attempts. 1259 00:43:00,160 --> 00:43:01,719 I've seen links to emails. 1260 00:43:01,720 --> 00:43:03,999 I haven't seen a lot of responses. 1261 00:43:04,000 --> 00:43:05,859 I'd absolutely love to see that fixed. 1262 00:43:05,860 --> 00:43:07,929 And if you know of the right people to 1263 00:43:07,930 --> 00:43:09,699 talk to, it would be great to get in 1264 00:43:09,700 --> 00:43:11,349 contact and work towards the solution. 1265 00:43:11,350 --> 00:43:12,999 I think we'd all be better off if we saw 1266 00:43:13,000 --> 00:43:14,079 that happen. 1267 00:43:14,080 --> 00:43:15,080 Thanks. 1268 00:43:16,060 --> 00:43:17,589 Just a quick reminder for the people that 1269 00:43:17,590 --> 00:43:18,819 are leaving right now. 1270 00:43:18,820 --> 00:43:20,109 First of all, you're doing a great job 1271 00:43:20,110 --> 00:43:21,759 being very quiet. That's nice. 1272 00:43:21,760 --> 00:43:23,769 And please also take all your trash. 1273 00:43:23,770 --> 00:43:25,840 Thank you. And now number four, please. 1274 00:43:26,980 --> 00:43:29,169 Yeah. So second question, as we have so 1275 00:43:29,170 --> 00:43:30,170 much time, 1276 00:43:31,330 --> 00:43:33,639 what if I set up my email server 1277 00:43:33,640 --> 00:43:36,159 now and as you said it 1278 00:43:36,160 --> 00:43:38,349 last week, we cannot really do anything 1279 00:43:38,350 --> 00:43:39,999 about it because it's completely 1280 00:43:40,000 --> 00:43:41,000 optional. 1281 00:43:41,830 --> 00:43:43,989 What's your suggestion to 1282 00:43:43,990 --> 00:43:45,339 to what to deploy now? 1283 00:43:45,340 --> 00:43:46,299 What to do now? 1284 00:43:46,300 --> 00:43:48,280 Because apparently it's very broken. 1285 00:43:50,260 --> 00:43:52,329 I mean, I cannot do anything 1286 00:43:52,330 --> 00:43:54,429 about it. Right. Or what's your point? 1287 00:43:54,430 --> 00:43:56,589 Yeah, I mean, you're 1288 00:43:56,590 --> 00:43:57,039 correct. 1289 00:43:57,040 --> 00:43:58,959 I don't have a good I don't have a magic 1290 00:43:58,960 --> 00:44:00,549 pill here that says the fixes, these 1291 00:44:00,550 --> 00:44:01,989 problems. 1292 00:44:01,990 --> 00:44:03,459 It has been a slow deployment. 1293 00:44:03,460 --> 00:44:04,919 We're still not in a good spot. 1294 00:44:04,920 --> 00:44:06,669 We have a lot of work to do. 1295 00:44:06,670 --> 00:44:09,009 I would keep your eye out for these next 1296 00:44:09,010 --> 00:44:11,409 couple of proposals, see where they go, 1297 00:44:11,410 --> 00:44:13,389 watch them, support them if your operator 1298 00:44:13,390 --> 00:44:16,089 doesn't support to talk to them. 1299 00:44:16,090 --> 00:44:18,009 But, yeah, as an individual operator, 1300 00:44:18,010 --> 00:44:20,169 you're not in a great spot. 1301 00:44:20,170 --> 00:44:21,909 So there's this basically we're just 1302 00:44:21,910 --> 00:44:24,369 waiting for new SMTP proposals 1303 00:44:24,370 --> 00:44:26,499 and drafts that that make it 1304 00:44:26,500 --> 00:44:28,149 not optional or. 1305 00:44:28,150 --> 00:44:30,219 Yeah, I mean, we're kind of stuck. 1306 00:44:30,220 --> 00:44:31,899 I mean, I'm stuck just as much as you 1307 00:44:31,900 --> 00:44:32,889 are. 1308 00:44:32,890 --> 00:44:35,229 I mean, we've measured 1309 00:44:35,230 --> 00:44:36,189 what the world looks like. 1310 00:44:36,190 --> 00:44:38,379 We've brought this to light and our 1311 00:44:38,380 --> 00:44:40,479 hope as academics of kind of doing 1312 00:44:40,480 --> 00:44:41,799 this measurement of showing this is a 1313 00:44:41,800 --> 00:44:43,209 problem is the kind of help motivate 1314 00:44:43,210 --> 00:44:45,669 those along to help people say, look, 1315 00:44:45,670 --> 00:44:47,199 this is something we need to be paying 1316 00:44:47,200 --> 00:44:48,219 attention to. 1317 00:44:48,220 --> 00:44:50,139 Having eighty percent of mail just not 1318 00:44:50,140 --> 00:44:52,899 being encrypted is not acceptable. 1319 00:44:52,900 --> 00:44:54,969 But it's the same as 1320 00:44:54,970 --> 00:44:57,069 an EDP. It's going to take some time. 1321 00:44:57,070 --> 00:44:58,209 It's going to take some time to figure 1322 00:44:58,210 --> 00:44:59,469 out the right way of doing this. 1323 00:45:06,050 --> 00:45:07,639 Another quick thing, please don't walk in 1324 00:45:07,640 --> 00:45:09,049 front of the cameras. That's not a smart 1325 00:45:09,050 --> 00:45:10,399 thing to do. 1326 00:45:10,400 --> 00:45:12,529 Microphone number one place 1327 00:45:12,530 --> 00:45:14,639 I with most of the images are 1328 00:45:14,640 --> 00:45:16,729 now authenticated. 1329 00:45:16,730 --> 00:45:19,099 Every provider still has their own 1330 00:45:19,100 --> 00:45:20,839 spam filtering solution, their own 1331 00:45:20,840 --> 00:45:22,969 blacklisting solution yourself 1332 00:45:22,970 --> 00:45:25,639 and the global 1333 00:45:25,640 --> 00:45:28,069 reputation project, for example. 1334 00:45:28,070 --> 00:45:30,409 So I think there are some out there I 1335 00:45:30,410 --> 00:45:33,079 don't know names off the top of my head, 1336 00:45:33,080 --> 00:45:35,269 but there are lists of IP addresses. 1337 00:45:35,270 --> 00:45:37,219 Spamhaus maintains a set of these 1338 00:45:37,220 --> 00:45:39,469 different providers on the set of these. 1339 00:45:39,470 --> 00:45:41,449 I think a lot of the commercial providers 1340 00:45:41,450 --> 00:45:43,250 consider this kind of their secret 1341 00:45:44,420 --> 00:45:46,039 of their company. 1342 00:45:46,040 --> 00:45:48,199 Yahoo! Or Gmail can say, look, we we 1343 00:45:48,200 --> 00:45:49,639 we prevent more spam. 1344 00:45:49,640 --> 00:45:51,229 That's a selling point to these 1345 00:45:51,230 --> 00:45:52,219 companies. 1346 00:45:52,220 --> 00:45:54,559 And so I haven't seen big companies like 1347 00:45:54,560 --> 00:45:56,539 that coming out saying this is what we do 1348 00:45:56,540 --> 00:45:58,369 because they consider it part of their 1349 00:45:58,370 --> 00:46:00,049 business model. 1350 00:46:00,050 --> 00:46:02,239 And so I think 1351 00:46:02,240 --> 00:46:03,889 mail operators could tell you a better 1352 00:46:03,890 --> 00:46:05,749 list than I can of what people trust and 1353 00:46:05,750 --> 00:46:06,919 they don't. I know they're out there, but 1354 00:46:06,920 --> 00:46:08,479 I don't have one to tell you off top of 1355 00:46:08,480 --> 00:46:09,139 my head. 1356 00:46:09,140 --> 00:46:10,140 OK, thanks. 1357 00:46:12,320 --> 00:46:14,119 This all oh, the Internet go had 1358 00:46:15,350 --> 00:46:16,909 some problems with the email encryption 1359 00:46:16,910 --> 00:46:19,149 ties to DNS problems, DNA, 1360 00:46:19,150 --> 00:46:21,289 DNA, SEC, hard to run, DNS 1361 00:46:21,290 --> 00:46:23,389 curve is not deployed. 1362 00:46:23,390 --> 00:46:24,949 Are there any technologies coming up 1363 00:46:24,950 --> 00:46:25,950 here? 1364 00:46:27,360 --> 00:46:29,669 I know no more or less than 1365 00:46:29,670 --> 00:46:31,800 everyone else does about the DNS space, 1366 00:46:33,150 --> 00:46:35,609 I think we've talked to about DNS 1367 00:46:35,610 --> 00:46:37,379 for quite a while. We still haven't seen 1368 00:46:37,380 --> 00:46:39,329 massive deployments of it. 1369 00:46:39,330 --> 00:46:41,009 Some there's it's a very split world. 1370 00:46:41,010 --> 00:46:42,539 Some people are very much pushing for it. 1371 00:46:42,540 --> 00:46:44,099 Some people are very much hating against 1372 00:46:44,100 --> 00:46:46,949 it. I think in many ways that hasn't 1373 00:46:46,950 --> 00:46:47,950 been resolved. 1374 00:46:49,470 --> 00:46:50,969 There are some solutions to some of the 1375 00:46:50,970 --> 00:46:53,099 problems. Some people say that DNS is not 1376 00:46:53,100 --> 00:46:55,379 the place to solve this problem 1377 00:46:55,380 --> 00:46:58,229 that really like AZN in the world of 1378 00:46:58,230 --> 00:46:59,549 you want to have this end to end 1379 00:46:59,550 --> 00:47:00,959 encryption. That doesn't depend on 1380 00:47:00,960 --> 00:47:02,609 whether DNS is broken or not. 1381 00:47:02,610 --> 00:47:04,380 And in some ways, this is kind of 1382 00:47:05,760 --> 00:47:07,889 a personal war in many cases of 1383 00:47:07,890 --> 00:47:09,899 what people are pushing for. 1384 00:47:09,900 --> 00:47:12,069 So I don't have a good answer to that. 1385 00:47:12,070 --> 00:47:13,070 We'll see what comes. 1386 00:47:14,960 --> 00:47:17,519 Microphone number four, please. 1387 00:47:17,520 --> 00:47:19,819 I last time I checked, 1388 00:47:19,820 --> 00:47:22,789 there weren't Denmark, 1389 00:47:22,790 --> 00:47:24,589 are you ready? 1390 00:47:24,590 --> 00:47:26,659 Do you know if it's published yet 1391 00:47:26,660 --> 00:47:29,199 or are some discussions about 1392 00:47:29,200 --> 00:47:30,619 mailing lists? 1393 00:47:30,620 --> 00:47:32,779 Do you know the current state of it? 1394 00:47:32,780 --> 00:47:33,919 I believe it's published. 1395 00:47:33,920 --> 00:47:35,989 I think it happened either in 1396 00:47:35,990 --> 00:47:38,419 very early 2015 or somewhere around 1397 00:47:38,420 --> 00:47:40,489 there. If it is not finalized, 1398 00:47:40,490 --> 00:47:42,529 it is very much to the point where it's 1399 00:47:42,530 --> 00:47:44,329 stable and people are using it today. 1400 00:47:47,430 --> 00:47:49,349 Internet, please. 1401 00:47:49,350 --> 00:47:51,119 You said there's no easy solution for end 1402 00:47:51,120 --> 00:47:53,279 to end encryption in the near future. 1403 00:47:53,280 --> 00:47:55,529 Have you heard about pretty easy privacy? 1404 00:47:55,530 --> 00:47:57,479 It's coming up next month. 1405 00:47:58,730 --> 00:47:59,730 I don't quite follow. 1406 00:48:01,190 --> 00:48:03,319 Have you heard about pretty easy 1407 00:48:03,320 --> 00:48:05,209 privacy and what are your thoughts about 1408 00:48:05,210 --> 00:48:06,630 this PGP? 1409 00:48:07,640 --> 00:48:09,889 I it's very easy 1410 00:48:09,890 --> 00:48:11,809 to set up end to end encryption for 1411 00:48:11,810 --> 00:48:13,929 email, and it's going to be set up. 1412 00:48:13,930 --> 00:48:15,439 I don't know the details of offhand. 1413 00:48:15,440 --> 00:48:16,440 OK. 1414 00:48:17,590 --> 00:48:20,049 Number four, please, thank you for 1415 00:48:20,050 --> 00:48:22,449 your enlightened talk, 1416 00:48:22,450 --> 00:48:25,449 could you tell us, do you have any 1417 00:48:25,450 --> 00:48:26,530 best practices 1418 00:48:28,600 --> 00:48:30,669 in your paper or have you 1419 00:48:30,670 --> 00:48:32,559 in your or for that? 1420 00:48:32,560 --> 00:48:34,629 I mean, I think the best practices 1421 00:48:34,630 --> 00:48:37,809 have been outlined by the male community. 1422 00:48:37,810 --> 00:48:39,189 And these are very much to use these 1423 00:48:39,190 --> 00:48:41,349 protocols to actually be using 1424 00:48:41,350 --> 00:48:43,629 them to use DMARC 1425 00:48:43,630 --> 00:48:45,159 and to enable start. 1426 00:48:45,160 --> 00:48:47,019 Tell us. I mean, that's the kind of the 1427 00:48:47,020 --> 00:48:48,609 point we're at right now is the best 1428 00:48:48,610 --> 00:48:51,639 practices are to enable these protocols. 1429 00:48:51,640 --> 00:48:53,709 Beyond that, it tends to be very 1430 00:48:53,710 --> 00:48:55,659 application specific. 1431 00:48:55,660 --> 00:48:57,099 Big male providers have very different 1432 00:48:57,100 --> 00:48:58,659 needs. And a small organization, 1433 00:48:59,960 --> 00:49:02,649 I would say, go and read about them, 1434 00:49:02,650 --> 00:49:04,209 figure out which of these makes sense to 1435 00:49:04,210 --> 00:49:05,230 use in your organization. 1436 00:49:08,400 --> 00:49:09,450 Anybody else, 1437 00:49:10,470 --> 00:49:11,849 this is such a long queue. 1438 00:49:11,850 --> 00:49:13,699 Oh, number five, go ahead. 1439 00:49:13,700 --> 00:49:15,989 Why do you have suggestions? 1440 00:49:15,990 --> 00:49:18,149 Where they are tools or websites 1441 00:49:18,150 --> 00:49:20,399 like for us to test 1442 00:49:20,400 --> 00:49:22,169 your own mail server, if you have set up 1443 00:49:22,170 --> 00:49:24,329 demarked AECOM and so on correctly, 1444 00:49:24,330 --> 00:49:25,409 they are out there. 1445 00:49:25,410 --> 00:49:26,609 If you Google for them. I don't know the 1446 00:49:26,610 --> 00:49:27,869 domains off the top of my head, but if 1447 00:49:27,870 --> 00:49:29,009 you Google, there's a couple of right 1448 00:49:29,010 --> 00:49:30,539 away that come up that will do the tests 1449 00:49:30,540 --> 00:49:31,540 for you. 1450 00:49:35,420 --> 00:49:37,489 I think we're done, 1451 00:49:37,490 --> 00:49:39,050 please. Once again, thanks, Sakir.