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!
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 Sakia, who you might know
as the developer of Seamap, which
is a thing that allows you to map lots
of beautiful IP addresses.
And I think more recently was also
involved in Log Jam,
which is not a security nightmare on its
own. So please welcome Zacchia.
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 being
the first thing that comes to a lot of
people's minds is PGP
or mine views 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 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 to authenticate
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 how does
it work?
When used to mean email, usually you
send us from your laptop, you send it to
your organizations, some TP server.
This may just be something that your
department or your company runs.
And this is submitted over some TPE,
but as we call it, some type submission
and it gets that server and server hangs
on to it and essentially then takes
responsibility for getting it to the
destination organization.
So your SMTP server and your local
organization does a DNS look
up for the Amex record for the domain
you're trying to send the email to,
and it gets back eventually in name of
email server and an IP address
and then your local TPE
server, your organization delivers the
email to the destination organization
server, which holds on to it
until later on this hour, comes
and collects using Pop three or
IMAP or three the web interface
in the first thing. The last step in this
process uses
Telos very much in the way that https
is to for keeps your
client connects to verifies the
certificate.
You can say I'm only going to connect
over HSDPA, so I'm only going
to connect using class.
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
organization to the next organization?
And by default, at the beginning,
as S&P was originally conceived, there is
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 use for some of our
most trusted communication.
And so we added in essentially these
extensions to some TCP
and these allow these more security
features. They allowed us to encrypt
email and translate. 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 is
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 class and essentially
start classes to illustrate some TPE.
And what it allows is essentially for
the message should be encrypted in
transit when it goes over the Internet.
And the protocol is pretty simple.
You actually start a normal ENTP session
like you would if you're sending a
message and clear text,
you create you start TCAP handshake.
I'm twenty five, you send a hello.
The server then responds to the features
that it supports and what those features
are going to be. Start RTLS.
So then you send this start to command.
The service has great I support start to
you and then you do a normal Tlas
handshake. You send a client.
Hello, the server sends a server.
Hello. You complete the whole handshake
after which this negotiation finishes,
you are back and S&P and you can deliver
your mail and it's sent over this
session.
However, this is done a little bit
differently than this is done in TDP.
And one of the reasons is, is that
the way we use to lessen ENTP
is opportunistic.
And the main reason is, is because the RC
actually says a server may not
require that mail be sent over
an encrypted channel. It may not require
that to be used.
So that means that if it can't
be used, then your only alternative is to
sending clear text.
So because of this service, do not
validate any destination certificates.
They get the certificate and they
essentially discard it.
They don't really look at it because if
they looked at it, they realized they
don't like it, it's expired.
Then the alternative is to send a message
in clear text, which is really not any
better than just sending the certificate
over an encrypted channel, thus using an
expired certificate.
So at the end of the day, nobody
validates any certificates.
And because of that, essentially nobody
really provisional certificates,
people just a self signed cert and never
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 to from all servers
because so many don't support it yet.
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 one hundred
percent of servers supported start
to less, there's still an additional
layer of essentially
redirection within some top.
And that's because unlike
when you go to a domain, you get an IP
address.
Right back when I say I want to send
an email to Gmail dot com, I go
and I do this and record look up for
Gmail dot com and I essentially get back
a list of names in this might be
like S.A.G..
Gmail dot com, and then I go and I
do a second DNS look up for
what is the IP address for some TP dot
Gmail dot com and eventually I transmit
mail to that IP address.
So you say, well, what do you put on the
certificate?
Well, you could you have two options.
You could put the name of the actual ENTP
server itself, S&P, A.P., that Gmail dot
com. Or we could put the actual domain
Gmail dot com
put in the name of the of the server
itself, doesn't actually really do
anything for us, because if you are
being man in the middle, if you're being
attacked when you went to request the
name of this Amex 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 still be provided by
the attacker.
And so the alternative, on the other
hand, that makes, I think, more sense to
all of us off hand as well.
Put the actual domain itself, put Gmail
dot com on the certificate, on the mail
server, and then we know are 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, the Aleksa list
and approximately twenty
five percent of these actually delegates
their email out to someone else.
And so all of a sudden, Gmail, if Gmail
needs a certificate that's going to match
the domain of the email you're sending to
also needs to have
a certificate that matches six percent
of domains on the Internet, potentially.
And it's not to say this is entirely
infeasible, that we could create
technology that handles this, that we
could create some sort of constrained
certificate that is not immediately
obvious how to do this today.
There isn't an immediate solution where
we can start to acquire start tools.
So if we start to
look at data, this is
the essentially the amount of messages
in and out of Gmail
that you start to lose,
and we're actually have made significant
progress over the last two years.
And we're at the point where nearly
80 percent of messages
that are outbound, we're able to initiate
connections for and just over 60
percent of inbound connections initiate a
lost connection.
However, at the same time, this was
actually due to a couple of very large
providers changing their start to
policies.
There's this very, very large jump in
early 2014 that essentially
is when Yahoo!
And Hotmail diploid start to lose.
And so it's actually once you remove
these, it's rather
stagnant.
We are slowly increasing.
There are small number of servers 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 Gmail,
we see about 10 percent more email is
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 percent of email being
encrypted when Puddle came out, which
from as far as we can tell, is just
because people panicked and they try to
disable SSL free and they just
disabled all tools.
And the slowly recovered, we started to
encrypt email again.
But this is not what we want to see.
This is 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 Arcy for Facebook
mail, still has a certificate that
doesn't match anything.
They have a signed certificate.
It's valid just not for domain that has
anything to do with their mail servers.
And we're talking the top 10 in the world
of Sendmail,
and we actually just validators and AT&T
and Yahoo!
Are still initiating ask for connections
as of this morning.
This is not better for the long tail
of people, not in these top 10 in the top
most popular of the top
million domains, about 80 percent support
start to less.
About 34 percent have certificates that
match the server but don't really provide
any security.
And only zero point six percent 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 the state?
This is kind of sad.
If you go back and you look at
the common meal software that's being
used, a lot of these software don't
provide start to collapse by default.
In fact, the only people who actually do
both is Microsoft Exchange,
which is.
And there is some work to do default
in coming start tells you you need to
generate a certificate, you need to get
this set up. But for outgoing class,
there's really absolutely no reason
that postfix and Kumail are not
initiating start connections by
default.
So at the end of the day, what this
really boils down to is start
to less is protecting against passes,
eavesdropping, 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 to
lose. What is the simplest way
that I can eavesdrop on all these servers
that you start to less?
Well, the easiest way of doing
this is you watch for some TP
connections and you see this start
to last 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 ENTP
and I support Zak's.
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, OK, I'm
going to ignore that. I'm going to send
start Helus anyway, at which point
the attacker just replaces start
with Zak's, it gets the server
in the server says, I have no idea what
you want from me.
Why are you sending me access in?
This sounds like the dumbest
attack you could come up with, right.
Like why would you not man in the middle.
Why would you not do something a little
bit stealthier?
But we didn't internet white scans and we
looked for this. We looked at how what
percentage of messages were actually
garbled and we looked at what percentage
of email to and from Gmail
essentially were from these ISPs.
And it's astounding.
So let's take a moment, let's think in
96 percent of emails
from Tunisia are blocked
from starting a last session to
encrypt mail by some sort of network
device in between, that takes the start
to 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 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 you also find is Cisco actually
advertises this as a feature.
So what happens
is Cisco has the Cisco assay 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
to connection that goes through the Cisco
device and then they full 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.
But 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 to
connection.
And then we continue with the server and
you can still you start to last and
maybe it's not end to end, but at least
you won't be sending everything in to
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 next records for the
server? Was the IP address for
this mail server?
And because we know that no mail servers
ever validate the answers,
no. Those servers actually look at the
certificates to see our man talking to
the right mail server.
There's nothing that actually prevents
the DNS or from just lying and saying,
oh, the mail server, Google dot 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 forwarded 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 IPV
for scans, we asked every open
resolver on the Internet, what is the
next record and what is the IP address
for the mail servers, for Gmail dot com?
And we saw in hundreds
of Azis and sixty nine countries
falsified responses to what the answers
were. And when we go back, we see that
there's a small fraction for all
countries with about one out of every ten
thousand 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 minimal,
lower, 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 mis configured hopes
of hosts.
But we do see that it is happening.
So the state of of delivering
security is rather dismal,
we have start to last, 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 it sent from someone that was
authorized to send from the
source domain?
And this is help essentially
help us along the way in detecting spam,
and there have been three different
protocols that are essentially in
common use today, SPF
Deakin in Denmark, 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 set me send a mail for
it.
So essentially, Gmail says these are the
IP addresses that I owned that I control
of either the IP addresses of my SMTP
servers. Anything sent as me
from other ISPs 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 off hand?
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 in order Stepien gets a message,
it looks up the IP address that
receives mail from and it checks
if it was sent from the 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
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 d'Yquem, our domain
keys identified mail, and in essence,
what this allows provider to
do is to publish a public key again in
the DNS record that says expect
any email that comes for 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 has
an additional header in the message and
it essentially says,
these are the headers, I am taking a half
shove and this is the 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 dot com to say
what is your d'Yquem public key
off hand 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 d'Yquem,
but it has this fatal and
rather obvious flaw in it, which
is any attack or just removes the
signature in the mail is delivered
and some of the big mail providers kind
of got around this by caching
the different responses.
They know everything that comes from
Yahoo! Before has had
this this header 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,
Demarked was released and DMARC
essentially works with both SPF
and Kim and it essentially allows
the sender to publish a policy.
It's allowed just put out this DNS record
that says expect every message
sent to me, sent from me to have
a signature attached.
And if there's no signature attached,
then you can discard it.
And it probably
should have been originally published
with Kim when it originally came out.
But it did not it didn't come 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 the message and it seems
to either match the SPF record or
the Deakin record.
And for most parts, if you have one or
the other is correct, then the recipient
will accept the message.
From Jamal's perspective, this is going
rather well over
90 percent of email is actually
authenticated with either
SPF or a combination
of both their 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 and actually a
very different picture,
less than 50 percent domains have any SPF
policy defined and only about one
percent of domains have a demarked policy
at all.
Of those demarked policies,
only 20 percent actually say you should
reject a message that doesn't match
either the SPF or the decamps signature.
And for most of them, West says none.
What happens is that these
messages are essentially
returned to the sender.
They're 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 them because
sometimes signatures of messages change.
In fact, any time 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
altered. The deacon's signature no longer
matches.
And because of this, if you have a
district policy, all and
no one in your organization can use a
mailing list.
For SPF, maybe your emails for
it is through someone else, maybe it uses
a mailing list again
at the end of the day that emails
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 or 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 started to
use reject policies.
They're still very, very few overall.
So what do we do moving
going forward?
We're kind of in a dismal place today,
start to doesn't really do what we want
it to do. We probably want to know are
talking to the right mail server.
We probably want more people to be using
these signatures and actually validating
messages are what they say they were.
There are two proposals essentially
in and around the ATF right now.
One of them is some strict transport
security.
And this essentially is along the lines
of HÃ¸st phrase 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 Dickin.
There's a proposal called Arcaro
Authenticated received chain, which
essentially helps the process when
messages are altered, maybe we can have
multiple signatures.
We had the signature before this photo
was attached and maybe we add a different
hash when the photo was attached to a
trusted 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 and
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 no longer deployed start to less
or that we're observing this start to
less shipping behavior.
We're seeing these text messages being
corrupted and so we can hopefully track
over time to see where the popular
domains we need to go and harass to
actually go in and start to less on their
servers.
So in conclusion, the mill community has
started to deploy these new security
extensions, but I think we can all agree
we're not near the place where we want to
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 seventy
five percent of domains on the Internet,
you're not going to say I'm not going to
send it to the other 25 percent because
they don't have encryption. That's just
not going to 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 tools.
We'll see where that goes.
There are several proposals kind
of in the works, both Arc
Astra Transport Security, which should
help Ettalong 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 your question.
If you're on the stream, go on AFSC,
go on Twitter and ask
Rosignol Angel.
And if you need somebody to bring a
microphone to you, please raise your
hands.
And then that will probably happen to.
Let's start on microphone two.
Oh, hello for us.
Thanks for the very nice overview of the
current state, especially as viewed from
the other side of these insights from
Gmail are really very interesting in
Germany as quite a lobby for using
the NSA to solve some of these problems.
And there are already standards like
DAINE and everything to do things similar
to your SMTP Stockdale's.
You didn't mention that at all.
So what do you think about those options?
So Dean is a possibility.
It could be used as essentially a public
key.
I think a lot of people don't believe
that the NSA is going to be deployed
in the real world. That's the right
solution. I think it's on the right path
to getting something out.
But there's still very, very few domains
that use DNS is less than one percent
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.
They can, Zainal Angel,
please.
I had exactly the same question.
Thank you.
OK. And then microphone four, please.
Um, yeah. About the state's
proposal.
I'm wondering, why are you using a DNS
channel for it as an insecure channel
instead of doing it like HD
is actually doing it and using the
if you want to have a secure
connection, then inside that already
encrypted channel, transmit
information like, OK, but in the future,
I also want to have encrypted
connection and please stole my
certificate or something like that,
because I think that would be more
secure than you would have a trust on.
First, your security while your proposal.
You're relying basically that the DNS is
not, uh, 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 placed in start to
last, there's a little reason they can
also replace the other message
or that that would never happen, whereas
DNS has a little bit more roundabout's.
It's a different path.
There's caching in place.
End of the day, you're right, neither are
perfect solutions
and I personally would like to see both
happen.
Number one, please.
Hello, Latymer, the Bromell daughter, you
are in your research with Google,
you count things like
certificate validation and
support or for outdated
ciphers.
But as we know, start lists are
only protects against passive
attacks and actually certificate
validation and nothing.
And so the question is why?
I'm not quite sure if I follow, why are
we not building certificates or
why are we not doing what are
in active?
Because actually accept an invalid
certificate and not checking
for outdated Cy-Fair allows
you to keep a connection and creeped it.
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 offhand.
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
for five or 10 years ahead of
us. Is there any hope for decentralized
e-mail, basically hosting your own email
server or. That's pretty much dead at
this point.
Yeah, this
is a very valid point.
It's becoming more and more complicated
by the day to deploy mail
server correctly and
I.
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, 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 will 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 going to say
that even if you deploy everything
correctly today, like you know
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 slight moving forward with
a SMTP, CDS and ARCC,
maybe I misunderstood it or is slightly
misleading because as far
as I understood you were, you were saying
that HECS offers
public keep painting, which it does not.
Or are you saying that
SMTP CDS offers public
opinion?
So I am sure it's similar along
the lines of HECS or PKP
along those lines where you can panichi
your correct HECS.
HECS is not pinnies specific key,
but I believe ESTs will be able to
do that.
OK, thanks.
Signal angel, please, isn't
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 to detect
fraudulent messages, how do they catch
spam even in the case
of PGP?
A lot of your metadata is still in the
clear that if we are sending the mail to
who you're sending mail from, the subject
of the message or 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 Dekha demarked, deployed
a small domain and sent
email to some
other domain and then get a response
from from Google and a Deacon
DeMarco report telling you, OK,
I got this one e-mail from there.
So, you know, OK, he's forwarding
to Gmail.
So we haven't looked at it, but be a very
interesting kind of avenue to go down.
Number one, please, hello,
coming back to the Senate to pass this
proposal. I'm the guy with the guitar, to
be sure.
I really don't like it.
The main point is it might be very
well for large companies
like Gmail and Yahoo!
And Comcast and Microsoft, like the Air
Force, or if you talk to animal
experts or to small operators, to
universities, they want they want
to deploy it because it
needs out-of-band authentication over
https anyway.
So you need to set up a website
in addition to the MTA and have another
party communicating with you.
So, I mean, it's nice for large, large
hosting providers, but it's not for all
of the small MTA out there.
Sure.
I don't know if you have GitHub issue
you're referring to offhand, but I can
answer the question more broadly.
DNS is already used pretty pervasively
as what's being used for Demarcates being
useless for SPF.
So it's not that people need to really
deploy new technology.
There is potential to use new ones.
And personally, I agree that there should
there there's no reason we couldn't have
something along this.
The way of HBK
for your server communicates it as well
as through an out-of-band way
through DNS.
So ideally, I would
like to use something like tech, not
data in addition to the N.S.A.
extension that will do something like
it just as far as to be sure,
and then have a two year extension like
tech that has a proper control over
properties as well.
I mean, they basically just cache stuff
and take it off DNS or out
of a well known euro
without a penalty location, which
kind of sucks, in my opinion.
Yep. There's no perfect solution here
right now.
Yeah, I agree.
Internet plays.
Maybe it's easier to move all these big
corporations to secure email handling.
But another nice thing would be to
decentralized email servers,
um, which solves other problems.
Is there a combined way?
I think these 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
expertize 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 e-mail providers or small email
providers are good versus bad, but I
think it's in a somewhat independent
argument of this.
Number two, please.
OK, as we have some more time left, are
coming back to you in a sec.
Again, I understand the 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 e-mail traffic in
this world.
So if those that
the SEC, at least for resolving and for
publishing the domains, I mean, Google is
using the Nesic for quite some point,
at least some of the problems already
would be solved, like faking a mixed
record and everything like that.
And if they employ, then at
least for their outgoing connections,
publish records for the incoming
connections. Lots of traffic in the
Internet would already be
solved. From all of the problems you
mention and thinking far, you would
have end to end security with things like
Open PGP, Key Esmay and everything
like that.
So wouldn't it be just better to push
the Intersect more?
Again, yes, the insect is
a technical possibility, I haven't
seen many of the big providers
use DNS, SEC requires
all of the clients still support it
and yes, it technically solves it.
But I think we are seeing that the SEC is
played 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.
OK, is there a middle
large providers in Germany already using
it and not having really big problems
with it?
So, I mean, even if we go
back and look at key cyesis,
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 this even worth
deploying or building a technology
even on a thousand twenty four RSA keys
that we know are probably going to be
insecure in a matter of years, that we're
pushing for it to be used in the next
couple of years? There's a question of is
this the right thing to be putting our
effort forth again?
Yes, in an optimal
world, we would deploy every technology
solution possible. Everyone would use the
second. The 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 is saying don't
use DNS.
Nothing is preventing organizations from
using it or from verifying it
is really up to the organization whether
or not they want to deploy DNS
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 also the reasons that people
like this talk mentioned all the problems
of the six thousand twenty
four cases are basically solved in a few
years. We have new algorithms they
already deployed, getting shorter keys,
following suspected sites and everything.
So the is evolving.
So I wouldn't keep it off
and I'd be happy to see that.
See where that goes.
OK, 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
methods do not and 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 email server
now and as you said it
last week, we cannot really do anything
about it because it's completely
optional.
What's your suggestion to
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?
Yeah, I mean, you're
correct.
I don't have a good I don't have a magic
pill here that says the fixes, these
problems.
It has been a slow deployment.
We're still not in a good spot.
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 to talk to them.
But, yeah, as an individual operator,
you're not in a great spot.
So there's this basically we're just
waiting for new SMTP proposals
and drafts that that make it
not optional or.
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 of showing this is a
problem is the kind of help motivate
those along to help people say, look,
this is something we need to be paying
attention to.
Having eighty percent of mail just not
being encrypted is not acceptable.
But it's the same as
an EDP. It's going to take some time.
It's going to 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 place
I with most of the images are
now authenticated.
Every provider still has their own
spam filtering solution, their own
blacklisting solution yourself
and the 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.
Spamhaus maintains a set of these
different providers on the 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 we
we prevent more spam.
That's a selling point to these
companies.
And so I haven't seen big companies like
that coming out saying this is what we do
because they consider it part of their
business model.
And so I think
mail operators could 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 top of
my head.
OK, thanks.
This all oh, the Internet go had
some problems with the email encryption
ties to DNS problems, DNA,
DNA, SEC, 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 to about DNS
for quite a while. We still haven't seen
massive deployments of it.
Some there's 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 like AZN in the world of
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.
I last time I checked,
there weren't Denmark,
are you ready?
Do you know if it's published yet
or are 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?
I it's very easy
to set up end to end encryption for
email, and it's going to be set up.
I don't know the details of offhand.
OK.
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
in your or for that?
I mean, I think the best practices
have been outlined by the male community.
And these are very much to use these
protocols to actually be using
them to use DMARC
and to enable start.
Tell us. I mean, that's the 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 male providers have very different
needs. And a small organization,
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 queue.
Oh, number five, go ahead.
Why do you have suggestions?
Where they are tools or websites
like for us to test
your own mail server, if you have set up
demarked AECOM 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
away that come up that will do the tests
for you.
I think we're done,
please. Once again, thanks, Sakir.