 Now, for the next talk, we will be learning about the state of email security in 2015, which is an important topic, as you all know. Email is a thing that people use. And email is also a thing that has lots of security problems. And our speaker today will be Sakir, who you might know as the developer of CMAP, which is a thing that allows you to map lots of beautiful IP addresses. And I think more recently, he was also involved in Logjam, which is another security nightmare in its own. So please welcome Sakir. Thank you. Well, thank you for the introduction. It's good to be back here again this year. So I mostly want to look at today, how is your email protected? When we talk about email security, I think the first thing that comes to a lot of people's minds is PGP or S-Mind, these end-to-end encryption technologies. But the reality is a minuscule amount of emails actually encrypted using PGP, and even if you are using PGP, all your metadata is still sent in the clear. And so what happens for all the email we send on a daily basis that doesn't use PGP? Well, on the back end, mail operators have deployed a range of protocols to help secure mail and to authenticate mail that you receive. So today, I want to talk about what those protocols are, essentially how we've come along in time, how well they're deployed today, and then the attacks that we're seeing in the wild against mail servers. And the content in this talk is actually based on a large collaboration between the University of Michigan, the University of Illinois, and Google. And so the data we're looking at in this talk is either based on internet-wide scanning or essentially the email that came to and from Gmail in the past two years. So when I say email delivery security, what am I talking about? Well, if we start at the very beginning and we just say, well, how does email work? When you submit an email, usually you send this from your laptop, you send it to your organization's SMTP server. This might just be something that your department or your company runs. And this is submitted over SMTP, but as we call it SMTP submission. And it gets that server and that server hangs onto it and essentially then takes responsibility for getting it to the destination organization. So your SMTP server and your local organization does a DNS lookup for the MX record for the domain you're trying to send the email to. And then it gets back eventually a name of a mail server and an IP address. And then your local SMTP server, your organization, delivers the email to the destination organization server, which holds onto it until later on the user comes and collects it using POP3 or IMAP or through the web interface. And the first and the last step in this process uses TLS very much in the way that HTTP uses TLS for HTTPS. Your client connects, it verifies a certificate. You can say I'm only going to connect over HTTPS or I'm only going to connect using TLS. What I want to focus on today actually is the other part, the part in the middle. And this is the part that goes over essentially the internet. How do you communicate mail from your one to organization to the next organization? And by default at the beginning, as SMTP was originally conceived, there was absolutely no security built in. Everything was sent in the clear text, and you trusted every email that you received came from the original sender. And over the years, we realized this was actually probably not exactly what we wanted for our email. One of the technologies we used for some of our most trusted communication. And so we added in essentially these extensions to SMTP. And these allow these more security features. They allowed us to encrypt email and transit. They allowed us to authenticate the types of emails that we receive. However, none of you have probably ever seen these technologies unless you're an actual mail operator. All of this is invisible to the end user. You don't know if your email was encrypted when it was sent from my university to your university. You don't know if your university actually authenticated the email before it delivered it to you. And so today we want to look at, well, how well actually does this happen in practice? So the first protocol that comes to mind is probably the most well-known is Start TLS. And essentially, Start TLS is TLS for SMTP. And what it allows is essentially for the message to be encrypted in transit when it goes over the internet. And the protocol is pretty simple. You actually start a normal SMTP session like you would if you're sending message and clear text. You start a TCP handshake on port 25. You send a hello. The server then responds to the features that it supports. So one of those features is going to be Start TLS. So then you send this Start TLS command. The server says, great, I support Start TLS. And then you do a normal TLS handshake. You send a client hello. The server sends a server hello. You complete this whole handshake, after which this negotiation finishes, you are back in SMTP and you can deliver your mail and it's sent over this TLS session. However, this is done a little bit differently than this is done in HTTP. And one of the reasons is, is that the way we use TLS in SMTP is opportunistic. And the main reason is, is because the RFC actually says, a server may not require that mail be sent over an encrypted channel. It may not require that TLS be used. So that means that if TLS can't be used, then your only alternative is ascending clear text. So because of this, servers do not validate any destination certificates. They get this certificate and they essentially discard it. They don't really look at it because if they looked at it, they realize they don't like it, it's expired. Then the alternative is to send the message in clear text, which is really not any better than just sending the certificate over an encrypted channel that's using an expired certificate. So at the end of the day, nobody validates any certificates and because of that essentially, nobody really provisions any certificates. People just create a self-signed cert and everyone will trust it and no one's the wiser at the end of the day. And in the end, we aren't in the position to essentially require start TLS from all servers because so many don't support it yet. And we'll get into this a little bit later when we look at data. But it's actually even more complicated than that because even if 100% of servers supported start TLS, there's still an additional layer of essentially redirection within SMTP. And that's because unlike HTTPS, when you go to a domain, you get an IP address right back. When I say I want to send an email to gmail.com, I go and I do this MX record lookup for gmail.com and I essentially get back a list of names and this might be like smtp.gmail.com. And then I go and I do a second DNS lookup for what is the IP address for smtp.gmail.com and eventually I transmit mail to that IP address. So you say, well, what do you put on the certificate? Well, you could give two options. You could put the name of the actual SMTP server itself smtp.gmail.com or we could put the actual domain gmail.com. Putting the name of the server itself doesn't actually do anything for us because if you are being man in the middle, if you are being attacked, when you went to request the name of this MX record, essentially your DNS server would lie to you. The attacker would provide you a false name and then you would go ahead and use it and your certificate would match the false name but it would still be provided by the attacker. And so the alternative on the other hand makes I think more sense to all of us offhand as well, put the actual domain itself, put gmail.com on the certificate on the mail server and then we know we're connecting to the real server. But a huge number of people essentially delegate their email out. These are the mail providers for the top million domains on the Alexa list. And approximately 25% of these actually delegate their email out to someone else. And so all of a sudden gmail, if gmail needs a certificate, that's gonna match the domain of the email you're sending to, all of a sudden it needs to have a certificate that matches 16% of domains on the internet potentially. And it's not to say this is entirely infeasible that we couldn't create technology that handles this, that we couldn't create some sort of constrained certificate. But it's not immediately obvious how to do this today. There isn't an immediate solution where we can start to require start TLS. So if we start to look at data, this is essentially the amount of messages in and out of gmail that have used start TLS. And we actually have made significant progress over the last two years. We're at the point where nearly 80% of messages that are outbound, we're able to initiate connections for. And just over 60% of inbound connections initiate a start TLS connection. However, at the same time, this was actually due to a couple of very large providers changing their start TLS policies. There's this very, very large jump in early 2014 that essentially is when Yahoo and Hotmail deployed start TLS. And so it's actually, once you remove these, it's rather stagnant. We are slowly increasing. There are small number of servers that are slowly adopting these new protocols. But it's not like we're making these major leaps. These are actually just due to these small handful of providers that everyone uses. And when we zoom in, it's actually a very interesting graph. Here you'll notice, actually, you see it kind of goes up and down, up and down. And these are actually weekdays versus weekends. So for all email that comes in now of Gmail, we see about 10% more email that comes inbound is encrypted on weekends than on weekdays. And we suspect that this is because people go home and they use their personal email accounts. They send from their Hotmail account to their friends at Gmail. And then they go back to work during the weekdays. And the emails they send at work are actually less secure than all the personal emails they send on the weekends. As well, it's a fragile, fragile ecosystem. You see this big jump where we lose close to 20% of email being encrypted when Poodle came out, which from as far as we can tell is just because people panicked and they tried to disable SSL-3 and they just disabled all of TLS. And the slowly recovered and we started to encrypt email again. But this is not what we want to see. This is kind of a mess going on. And even for the big providers today, we're using bizarre ciphers. Even for these top providers of email on the internet, we're still negotiating RC4. Facebook Mail still has a certificate that doesn't match anything. They have a science certificate. It's valid just not for a domain that has anything to do with their mail servers. And we're talking the top 10 in the world that send mail. And we actually just validate this. And AT&T and Yahoo are still initiating RC4 connections as of this morning. This is not better for the long tail of people not in these top 10 and the top most popular. Of the top million domains, about 80% support start TLS. About 34% have certificates that match the server but don't really provide any security. And only 0.6% have a certificate that matches the domain such that you could actually validate that you were sending mail to the right person on the internet. So how did we end up in this state? This is kind of sad. If you go back and you look at the common mail software that's being used, a lot of these software don't provide start TLS by default. In fact, the only people who actually do both is Microsoft Exchange. Which I miss. And there is some work to do default incoming start TLS. You do need to generate a certificate. You do need to get this set up. But for outgoing TLS, there's really absolutely no reason that post fix and Q mail are not initiating start TLS connections by default. So at the end of the day, what this really boils down to is start TLS is protecting against passive ease dropping but it protects against nothing else. It does not protect against any sort of active attacks. So let's say I'm an active attacker and I want to disable start TLS. What is the simplest way that I can e-drop on all these servers that you start TLS? Well, the easiest, stateless way of doing this is you watch for SMTP connections and you see this start TLS command and you just replace it with a bunch of gibberish. And so I go and I say hello mail server and what do you support? And you say I support compression and I support ESMTP and I support x, x, x, x, x, x, x, x. And the client says great, I don't know what that is, I won't use it. And that sends clear text mail. Now the client could say, okay, I'm going to ignore that and I'm going to send start TLS anyway at which point the attacker just replaces start TLS with x, x, x, x. It gets to the server and the server says I have no idea what you want from me. Why are you sending me Xs? And this sounds like the dumbest attack you could come up with, right? Like why would you not man the middle of it? Why would you not do something a little bit stealthier? But we did an internet wide scans and we looked for this. We looked at what percentage of messages were actually garbled and we looked at what percentage of email to and from Gmail essentially were from these IPs and it's astounding. So let's take a moment to let this sink in. 96% of emails from Tunisia are blocked from starting a TLS session to encrypt mail by some sort of network device in between that takes the start TLS command and corrupts it. So these are the top 10 countries. If we look at the top 20, you start to see European nations. We keep going, we see almost every nation. And you wonder why? Well, why is this happening? Is this malicious? Are these countries? Are these nation states that are decrypting mail? What is going on here? And it's not immediately obvious. When you break down the types of organizations, you see everything. But what you also find is Cisco actually advertises this as a feature. So what happens is Cisco has these Cisco ASA devices, these Cisco firewalls, and they want to be able to inspect the mail that goes through the devices. And they are looking for maybe injection commands. They're looking for, maybe they're looking for spam. But the only way that they think they can do this is if they have access to the clear text email. So what they do is they corrupt any start TLS connection that goes through the Cisco device. And then they fill access to the clear text email. Now, of course, the downfall is every email that comes out of your nation now is sent in the clear. And this isn't really explained in the Cisco documentation that there's this giant downfall that all your email is now in the clear if you decide to look for spam. And of course, there are better solutions to this. The Cisco box could very well terminate the start TLS connection and then re-continue it with the server. And you can still use start TLS. And maybe it's not end to end, but at least you wouldn't be sending everything in the clear. Now, the second way that you could also do this attack would just be to lie about what the mail servers are. So when I go to do my DNS lookup, I ask what are the MX records for this server? What is the IP address for this mail server? And because we know that no mail servers ever validate the answers, no servers actually look at the certificates to see am I talking to the right mail server? There's nothing that actually prevents the DNS server from just lying and saying, oh, the mail server for Google.com is actually to this IP address. And they own that IP address. And all the email all of a sudden, they can redirect all the email through that host. And then they'll eventually forward it onto Gmail so that no one notices that the email went missing. But in the meantime, they've had access to all of the email content. So we again looked for this by essentially doing internet-wide scans for DNS servers. And we did these IPv4 scans. We asked every open resolver on the internet, what is the MX record? And what is the IP address for the mail servers for Gmail.com? And we saw in hundreds of ASs and 69 countries, falsified responses to what the answers were. And when we go back, we see that there's a small fraction for all countries is about what an out of every 10,000 pieces of mail that come to Gmail are from one of these IP addresses that's been falsified. But at the same time, this is kind of, this is a minimum or lower bound. Open DNS resolvers aren't supposed to be out there. They're only really being exposed inadvertently. And we can see that it's happening. But we don't necessarily know how much it's happening because we only see this glimpse of the misconfigured hosts. Well, we do see that it is happening. So the state of delivery security is rather dismal. We have start TLS, but at the end of the day, it's just protecting against these passive connection, against passive eavesdropper. We know that active attackers are able to corrupt connections. And we know that active attackers are corrupting connections. So what about authenticating mail? So authenticating mail has had a lot more attention to it. And that's because we essentially want to prevent spam. And so there have been several different protocols that have been put out by mail providers that essentially allow a mail provider when they receive a message to try to determine if it was sent from the correct sender. Was this sent from someone that was authorized to send from the source domain? And this has helped essentially, helped us along the way in detecting spam. And there have been three different protocols that are essentially in common use today. SPF, DKIM, and DMARC, and I'll walk through each of them. So SPF is the simplest of the three. And it essentially allows a domain to put out a DNS text record that essentially lists the IP address or networks that are allowed to send mail for it. So essentially Gmail says, these are the IP addresses that I own, that I control through the IP addresses of my SMTP servers. Anything sent as me from other IPs is not me, and you can reject it. So you can set a policy of do I want a soft rejected meaning probably the mail provider will put it in the spam folder or take other action? Or do I just delete it offhand? What do you want me to do? As well, you can delegate records out and say, I'm letting all my email be hosted by Gmail. I will just defer my answer to Gmail. And it handles the real world cases fairly well. And so an recipient gets a message. It looks up the IP address that it received mail from and it checks if it was sent from that host. And then it makes the decision what to do. Now, for the most part, people aren't strictly just rejecting mail. They're essentially using this as another indicator within their spam filters of, might this have been spam? And that's because there are legitimate reasons that email gets forwarded at times. For example, this happens to me personally. I have an email address at my university which gets forwarded to my Gmail account. If Gmail had, or if domains had a strict policy, all of that email would be thrown away. So there are reasons that people don't do strict policies, but it is out there in some cases. The next one is de-kim, our domain keys identified mail. And in essence, what this allows a provider to do is to publish a public key, again, in the DNS record that says, expect any email that comes from me to be signed with this, the private key associated with this public key and throw away any messages where the signature of the message doesn't match the message. And so essentially, when the sender sends mail, attaches this signature as an additional header in the message and it essentially says, these are the headers I am taking a hash of and this is the hash of the body. This is the type of key. And then the recipient receives the message, they go and they look up the key and they check if it was signed, if the signature matches. But there's this peculiarity in this protocol where it's not obvious where the key is going to be located for the domain. I can't go to gmail.com and say, what is your de-kim public key offhand? Instead, that's actually included in the message itself and it can actually be different for every message. So there's this downfall that because of this, you have no way of knowing if a domain is going to sign the mail they send or not. You can get a message and know that the signature is invalid but if you just take the signature off all the way, if you just remove the header, there's no way for the recipient to actually detect whether the message should have been signed because there isn't any canonical place to go look for this configuration or to look for this key. So we deployed de-kim, but it has this fatal and rather obvious flaw in it, which is any attacker just removes the signature and the mail is delivered. And some of the big mail providers kind of got around this by caching the different responses. They'd know, oh everything that comes from Yahoo before has had this header, it has this signature, this message probably should have as well, but it was a pretty wishy-washy kind of configuration. And so a few years later, DeMark was released and DeMark essentially works with both SPF and de-kim and it essentially allows the sender to publish a policy. It's allowed to put out this DNS record that says expect every message sent from me to have a signature attached and if there's no signature attached then you can discard it. And this probably should have been originally published with de-kim when it originally came out, but it did not, it didn't came out until about, I think it was formally published within the last couple of years. So then a recipient checks the policy when it receives a message and it sees to either match the SPF record or the de-kim record and for most parts if one or the other is correct then the recipient will accept the message. From Gmail's perspective, this is going rather well. Over 90% of emails actually authenticated with either SPF, de-kim or a combination of both. There are very few messages that come through that don't have one of these headers attached or aren't from an allowed IP address. But this is very much dominated by a small number of very large providers. When you go and you look at the top million domains you see actually a very different picture. Less than 50% of domains have any SPF policy defined and only about 1% of domains have a de-marked policy at all. Of those de-marked policies, only 20% actually say you should reject a message that doesn't match either the SPF or the de-kim signature. And for most of them when it says none what happens is that these messages are essentially returned to the center. They're told back to the center that we receive this invalid message and you should know about it. And so essentially it's a policy for reporting but very, very few people actually use these in real life. And that's just because the mail ecosystem is so complicated. Very few people use de-kim because sometimes signatures of messages change. In fact, anytime you send a message through a mailing list you get that little footer at the bottom says this was sent through this mailing group click on this link to unsubscribe. When that happens the message is just altered. The de-kim signature no longer matches. And because of this if you have a de-kiss strict de-kim policy all of a sudden no one in your organization can use a mailing list. For SPF maybe your email's forwarded through someone else maybe it uses a mailing list. Again at the end of the day that email's rejected and we very much have this mantra that email should always go through. We aren't willing to just lose email. And so all of these policies have ended up being soft fails. What happens is messages get marked by spam filters and these go into being another essentially another parameter another variable that's calculated to determine whether the spam score for this message is too high. And slowly in the last year or so people have started to use reject policies but there are still very very few overall. So what do we do moving going forward? We're kind of in a dismal place today. Start TLS doesn't really do what we want it to do. We probably want to know we're talking to the right mail server. We'd probably want more people to be using decim signatures and actually validating messages or what they say they were. There are two proposals essentially in and around the ITF right now. One of them is SMTP strict transport security. And this essentially is along the lines of HSTS for HTTPS. It allows a domain to say look all the messages that you send to me need to be encrypted and they need to be encrypted to this public key. And I don't want you to deliver any mail to me unless it's encrypted with that key. And for the first time now you can actually be fairly certain if you have the right public key that you're actually sending it to the right destination. And essentially the way this is done is there's a DNS record that's published that says this is the key that you should use for me. It's not perfect. There is a chance that DNS record could be forged but it's a big step forward compared to where we were today. As a replacement to DKIM there's a proposal called ARC, our authenticated received chain which essentially helps the process when messages are altered. Maybe we can have multiple signatures. We had the signature before this footer was attached and maybe we added different hash when the footer was attached and we're gonna trust it because it comes from a mailing list provider that we trust. So we essentially add a little bit more complexity a little bit more flexibility to actually work with the real world. These are still very much being figured out. They're being deployed in practice very slowly because it's very hard to troubleshoot when messages disappear. To track progress, Google is publishing a transparency report that displays from the day prior the amount of email in and out of Gmail that was encrypted as well as how much email to each of the major providers was encrypted. As well within the census project we have launched a dashboard of the top servers that are of no longer deploy start TLS or that we're observing this start TLS stripping behavior we're seeing these TLS messages being corrupted. And so we can hopefully track over time and see what are the popular domains we need to go and harass to actually go and enable start TLS on their servers. So in conclusion, the mail community has started to deploy these new security extensions but I think we can all agree we're not near the place where we wanna be. We still don't have authentication. We still have no protection against any active attacks and there are attacks currently happening against the passive type of protection we have. Unfortunately, until there's this near pervasive deployment it's unlikely that adopters will require encryption. When you only have 75% of domains on the internet you're not gonna say, I'm not gonna send to this other 25% because they don't have encryption. That's just not gonna happen in the real world as much as we want it to. Gmail is currently working and discussing the possibility of showing indicators of whether a message was sent securely or not in hopes that they can start to pressure organizations into deploying start TLS. We'll see where that goes. There are several proposals kind of in the works both ARC and strict transport security which should help better along what's currently in place but at the end of the day we still have a lot of work that needs to be done. Questions? As always, for the questions just line up at the microphones I will call you when you can ask a question. If you're on the stream, go on ISC, go on Twitter and ask a signal angel and if you need somebody to bring a microphone to you please raise your hands and then that will probably happen too. Let's start the microphone too. Hello, first thanks for the very nice overview of the current state, especially as viewing from the US side all these insights from Gmail are really very interesting. In Germany there's quite a lobby for using DNSSEC to solve some of these problems and they're all already standards like Dain and everything to do things similar to your SMTP start TLS. You didn't mention that at all so what do you think about those options? So Dain is a possibility. It could be used as published essentially a public key. I think a lot of people don't believe that DNSSEC is going to be deployed in the real world or that's the right solution. I think it's on the right path of getting something out but there's still very, very few domains that use DNSSEC. It's less than 1% currently and what we need is a solution that works today. That's something that can be deployed little by little and something like stress transfer security allows us along the way while we figure out what a more long-term solution is. That signal angel please. I had exactly the same question, thank you. Okay and then microphone for please. Yeah, about the STS proposal. I'm wondering why you're using a DNS channel for it as an insecure channel instead of doing it like HSTS is actually doing it and using the, if you once have a secure start TLS connection then inside that already encrypted channel transmit information like okay but in the future I also want to have encrypted connection and please store my certificate or something like that because I think that would be more secure than you would have a trust on first use security while your proposal you're relying basically that the DNS is not modified. Yeah and this is a good point and I think in the best of cases we would have something along both cases where either one you trust. What we've seen is that essentially these are man the middle boxes that have access to the message and if they're already placing start TLS there's a little reason they couldn't also replace the other message or that that would never happen whereas DNS has a little bit more roundabout so it's a different path. There is caching in place and at the day you're right neither are perfect solutions and I personally would like to see both happen. Number one please. Hello Vladimir Dubrovin mail.au. In your research with Google you count things like certificate validation and support for outdated ciphers but as we know start TLS only protects against passive attacks and actually certificate validation and it's nothing so the question is why. I'm not quite sure if I follow why are we not validating certificates or why are we not doing what? Active because actually accepting invalid certificate and not checking for outdated ciphers allows you to keep a connection encrypted. True. My guess, I don't know if I have a perfect answer for you. My guess is that most mail servers will accept just about anything. This is because all of them are using open SSL except for exchange and they're kind of following what the open SSL defaults are. My guess is that the majority will accept insecure ciphers but I don't have numbers off hand. Number eight, please. Yes, hi. It seems that the big email providers are more and more moving towards a gated community approach more or less. Looking five or 10 years ahead of us is there any hope for decentralized email basically hosting your own email server or that's pretty much that at this point? Yeah, this is a very valid point. It's becoming more and more complicated by the day to deploy a mail server correctly. And I have no idea what it will look like, to be honest. I think we are seeing more and more people move to cloud providers because it's easier. If you deploy these technologies, it's not that any of these are proprietary. You can if you so desire to deploy them. It's just that it's a pain to. It's a pain to get all of these right. And that's one of the things that cloud providers do give you. So I suspect that we'll continue to see more people move to cloud providers but there will be always be that handful of organizations that still maintain their own mail servers. I was more going to say that even if you deploy everything correctly today like DMR, DMKIM, everything, you still get blacklisted. And that's more of the problem really because it's not a technical issue anymore. It's simply the big providers don't want to deal with anything besides the top 10. And that's it. So I don't have much good information on that, to be honest. Number four, please. On a slide, moving forward with SMTP, STS and ARC. Maybe I misunderstood it or it's slightly misleading because as far as I understood you were saying that HSTS offers public key pinning, which it does not. Or are you saying that SMTP STS offers public key pinning? So sure, it's similar along the lines of HSTS or HPKP. It's along those lines where you can pin a key. You're correct, HSTS does not pin a specific key but I believe STS will be able to do that. Okay, thanks. Signal angel, please. Is and all the transport layer security only one step on the road to end to end? Yeah, I think in the perfect world we would have end to end security. Every person here would be using PGP but the reality is it's not that easy. There's only a minuscule number of people that use PGP today. There are still some major challenges that stay ahead for PGP. Big mail providers are still running into problems of how do they detect fraudulent messages? How do they catch spam? Even in the case of PGP a lot of your metadata is still in the clear. The who you're sending the mail to, who you're sending mail from, the subjects of the message are sent along with this encrypted body. And so really I see this as an orthogonal issue. Until we have a good solution to end to end encryption which we just don't today and we don't have one in the foreseeable future we do need to be essentially looking at both of these different sides. Number two, please. Yes, I was wondering if you were looking into the privacy implications of those new technologies like for example if you have DMARC deployed at a small domain and send email to some other domain and then get a response from Google in a DMARC report telling you, okay I got this one mail from there so you know, okay he's forwarding to Gmail. So we haven't looked at it but it'd be a very interesting kind of avenue to go down. Number one, please. Hello, I'm coming back to the SMTPSS proposal. I'm the guy with the GitHub issue. I really don't like it. The main point is it might be very valid for large hosting companies like Gmail and Yahoo and Comcast and Microsoft like the offers are. If you talk to any mail experts or to small operators to universities they won't deploy it because it needs out of band authentication or HTTPS anyway. So you need to set up a web server in addition to MTA and have another party communicating with you. I mean that's nice for large hosting providers but it's not for all of the small MTAs out there. Sure, I don't know what GitHub issue you're referring to offhand but I can answer the question more broadly. DNS is already used pretty pervasively. It's what's being used for DMARC. It's being used for SPF. So it's not that people need to really deploy new technology, there's potential to use new ones. And personally I agree that there's no reason we couldn't have something along this the way of HP, KP, or HSTS where your server communicates it as well as through an out of band way through DNS. So ideally I'd like to use something like TAG an updated version in addition with an SMTP extension that would do something like HSTS for SMTP. Sure. And then have a TLS extension like TAG that has a proper key role over properties as well. I mean they basically just cache stuff and take it off DNS or out of a dot well known URL with out of band authentication which kind of sucks in my opinion. Yep, there's no perfect solution here right now. Yeah, I agree. Thanks. Internet please. Maybe it's easier to move all these big corporations to secure email handling but another nice thing would be to decentralized email service which solves other problems. Is there a combined way? I think these are orthogonal again. These technologies are being used by both small providers and large. I think what we're seeing is that there may not be the expertise to do it with small providers that we aren't seeing all the steps but there isn't anything in the technology itself that would prevent that. I think you can debate whether having large email providers or small email providers are good versus bad but I think that's a somewhat independent argument of this. Number two please. Okay, as we have some more time left coming back to DNSSEC again. I understand your argument it's not really used in the wild so far by many users but as you already shown in your slides there are a few very big providers controlling lots of the email traffic in this world. So if those would adapt DNSSEC at least for resolving and for publishing their domains, I mean Google is using DNSSEC for advice some points. At least some of the problems already would be solved like faking MX records and everything like that and if they would employ Dain at least for their outgoing connections, published records for the incoming connections, lots of traffic in the internet would already be solved from all of the problems you mentioned and thinking farther you would have end-to-end security with things like OpenPGP key, SMIME A and everything like that. So wouldn't it be just better to push DNSSEC more? Again, yes, DNSSEC is a technical possibility. I haven't seen many of the big providers use DNSSEC. It still requires all of the clients to still support it and yes, it technically solves it but I think we're seeing that DNSSEC has plagued with so many other issues. Technically, I think a lot of people in the world want to see a better solution before they push for widespread adoption. Okay, there are middle, large providers in Germany already using it and not having really big problems with it. I mean, even if we go back and look at key sizes, I think from day one, a lot of people will argue that the technology has some flaws in it that people ask the question, why is it even worth deploying? We're building a technology even on 1024 big RSA keys that we know are probably gonna be insecure in a matter of years yet we're pushing for it to be used in the next couple of years. So there's a question of, is this the right thing to be putting our effort forth? Again, yes, in the optimal world, we would deploy every technology solution possible. Everyone would use DNSSEC and a better solution would come out at the end of the day. But I think what we need is a better solution that everyone can use. And I don't think anyone's saying don't go use DNSSEC. Nothing is preventing organizations from using it or from verifying it. It's really up to the organization whether or not they want to deploy DNSSEC for themselves. But I think what we've seen is that not a lot of people are deploying it. And what that says is that we need to look at other alternatives that might be easier to deploy. But possibly it's also the reason that people like this talk mentioned all the old problems of DNSSEC like these 1024 bit keys, these are basically solved in a few years. We have new algorithms, they are already deployed, getting shorter keys, solving the package size, problem everything, so DNSSEC is evolving. So I wouldn't keep it off the watch list. And I'd be happy to see that, see where that goes. Okay, thank you. Do we have any more questions? We have astonishing 18 minutes left for Q&A. Go ahead, number one. Yeah, you were mentioning that by default a lot of open source MTAs do not encrypt either incoming or outgoing mail. Are you participating in mailing lists to try to change that policy? So I have seen some attempts, I've seen links to emails, I haven't seen a lot of responses. I'd absolutely love to see that fixed. And if you know of the right people to talk to, it would be great to get in contact and work towards the solution. I think we'd all be better off if we saw that happen. Thanks. Just a quick reminder for the people that are leaving right now. First of all, you're doing a great job being very quiet. That's nice. And please also take all your trash, thank you. And now, number four, please. Yeah, so second question as we have so much time. What if I set up my mail server now and as you said, start TLS, we cannot really do anything about it because it's completely optional. What's your suggestion to what to deploy now? What to do now? Because apparently it's very broken. I mean, I cannot do anything about it, right? Or what's your point on that? Yeah. I mean, you're correct. I don't have a magic pill here that says it fixes these problems. It has been a slow deployment. We're still not in a good spot and we have a lot of work to do. I would keep your eye out for these next couple of proposals, see where they go, watch them, support them. If your operator doesn't support TLS, talk to them. But yeah, as an individual operator, you're not in a great spot. So this is basically we're just waiting for new SMTP proposals and drafts that make it not optional? Yeah. I mean, we're kind of stuck. I mean, I'm stuck just as much as you are. I mean, we've measured what the world looks like. We've brought this to light and our hope as academics of kind of doing this measurement to showing this as a problem is to kind of help motivate those along to help people say, look, this is something we need to be paying attention to. Having 80% of mail just not being encrypted is not acceptable. But it's the same as HTTPS and HTTP. It's gonna take some time. It's gonna take some time to figure out the right way of doing this. Another quick thing, please don't walk in front of the cameras. That's not a smart thing to do. Microphone number one, please. Hi, with most of the emails are now authenticated. Every provider still has their own spam filtering solution, their own blacklisting solution. Are you aware of any open or global reputation project, for example? So I think there are some out there. I don't know names off the top of my head but there are lists of IP addresses, spam, house maintains, a set of these. Different providers present a set of these. I think a lot of the commercial providers consider this kind of their secret of their company. Yahoo or Gmail can say, look, we prevent more spam. That's a selling point to these companies. So I haven't seen big companies like that coming out and saying, this is what we do because they consider it part of their business model. And so I think mail operators could probably tell you a better list than I can of what people trust and they don't. I know they're out there, but I don't have one to tell you off the top of my head. Thanks. Is this all? Oh, the internet, go ahead. Some problems with email encryption ties to DNS problems. DNS sec is hard to run, DNS curve is not deployed. Are there any technologies coming up here? I know no more or less than everyone else does about the DNS space. I think we've talked about DNS sec for quite a while. We still haven't seen massive deployments of it. Some, it's a very split world. Some people are very much pushing for it. Some people are very much hating against it. I think in many ways that hasn't been resolved. There are some solutions to some of the problems. Some people say that DNS is not the place to solve this problem. That really, as in the world with HTTPS, you want to have this end-to-end encryption that doesn't depend on whether DNS is broken or not. And in some ways, this is kind of a personal war in many cases of what people are pushing for. So I don't have a good answer to that. We'll see what comes. Microphone number four, please. Hi. Last time I checked, there weren't DeMark RFC ready. Do you know if it's published yet? Or there were some discussions about mailing lists. Do you know the current state of it? I believe it's published. I think it happened either in very early 2015 or somewhere around there. If it is not finalized, it is very much to the point where it's stable and people are using it today. Internet, please. You said there's no easy solution for end-to-end encryption in the near future. Have you heard about Pretty Easy Privacy? It's coming up next month. I don't quite follow. Have you heard about Pretty Easy Privacy? And what are your thoughts about this? PGP? P-E-P. I don't... It's very easy to set up end-to-end encryption for email, and it's going to be set up next month. Don't know the details at all, Fjand. Okay. Number four, please. Thank you for your enlightened talk. Could you tell us, do you have any best practices in your paper, or have you earned your hope for that? I mean, I think the best practices have been outlined by the mail community, and these are very much to use these protocols, to actually be using DKIM to use DMARC and to enable STAR TLS. I mean, that's kind of the point we're at right now is the best practices are to enable these protocols. Beyond that, it tends to be very application-specific. Big mail providers have very different needs than a small organization. But I would say go and read about them. Figure out which of these makes sense to use in your organization. Anybody else? This is such a long Q&A. Oh, number five, go ahead. Hi, do you have suggestions where there are tools or websites like for HTTPS to test your own mail server if you have set up DMARC, DKIM, and so on correctly? They are out there if you Google for them. I don't know the domains off the top of my head, but if you Google, there's a couple of right-of-way that come up that will do the test for you. I think we're done. Please, once again, thank you, Sakia.