Okay, we have a band again with us and this time I think we will hear a little bit about
the authentication that auto config is especially ongoing work on we have been hearing
a couple of times today that this is still an issue from any client service and says
is ongoing work actually to make more interoperability here and we are happy to hear.
So this is an update on the efforts to for the authentication and auto config in email.
I gave the talk in the same place here last year, who is here in the talk last year?
So not even half, okay.
So the idea is we have this problem, everybody has to use passwords for email, it's understood
that this is the problem because they reuse the password everywhere the people because
they don't can't remember and that's a problem.
So how do we fix that for email?
Okay, wait.
Quickly about me, you've seen that maybe this morning, I have been for 25 years core
contributor to Thunderbird, I wrote the authentication logic in Thunderbird for IMF
POP 3 and SMTP, I have also been involved with four different implementations of OAuth
for mail specifically, including one product for a German ISP which had a few million users,
one for the add-on for Thunderbird in two products of mine in Perula and it was a review
for the Thunderbird implementation.
So I have firsthand experience with OAuth in this product and we need to support that in our
product.
I've also created software for other companies.
So what do we need?
Why do we need that?
First, from the point of view of the end users, what do we need?
They want to set up the email account once, they want to lock in, they want to set it up
and then they want it to just work.
They do the lock in once, between set up and then after that, they just wanted to work.
Like they want to have the email check coming in when the new mail notification that
I don't want to be randomly locked out, randomly redoing things, and obviously they want
don't want somebody to hack the email account.
Before I go into authentication, just a little segue into auto-config.
These standard out there, currently it's an actual, how do we call this, pseudo-not-sutus
standard, but something that's actually deployed, but not often, defector, thank you.
That's the work I was looking at.
The fact is standard, that was 15 years ago I realized that there's a big problem setting
up email accounts, and I couldn't even figure out and set up my own email accounts.
So I had to do something that was the, I've invented this protocol here.
You just go to a well-known URL based on the domain of your email address.
It gives you back this XML, which describes what the host name, the SSL, config, the authentication
method, your username, and all this information to set up your email account.
And ideally, with this information, you can set up the email account, the context,
the calendar, saying the file, thing, and a bunch of other stuff.
And importantly, for later on, the OAuth information can be included there as well.
This works in Thunderboards in 15 years, very successfully, because people keep using that
as, I think, like 60,000 people per day use this.
And we have configurations for, if you have an ISP that has more than 0.01 percent, no, 0.1
percent market share, then probably your configuration is in there.
And it can configure, I don't know, that sets 80-90 percent of mail accounts that can configure
to a phone figure already automatically.
There is a draft, an internet draft out there, which is adopted by the relevant ITF working
group, and it's on route to become an RFC real soon, now hopefully.
So then it becomes official RC.
This also unbuilding website here, ISPDB.net, where we're going to publish the configurations
of the major ISPs, and documentation, if you are implementing a mail client, how you can
implement this and query that and get the configuration for the main ISPs, and it's going
to be free to be, you can use that if you need that contact me, if you're mail client,
and you want this to talk to me.
There is an alternative proposal, which was just invented a few months ago by some people
at the IFTF, which has the exact same purpose, it's just a little bit not invented
to you thing.
They do things a little bit differently.
It uses DNS servers to find the server where the configuration is, and then it gets
the configuration via HTTPS from a JSON, and the difference is that it assumes the current
bad-back best practices, like it assumes that your username is identical to your email address,
which is a very good assumption, it's a fair, good configuration to do it this way,
but it does imply that the administrator specifically sets up the infrastructure for to work
with this, so that also implies that it can thus many mail conflicts of existing ISPs out
there, which this system cannot represent.
They doubted the current code name is Park or a PACC, however you want to pronounce that.
This is coming as an internet draft to be discussed as well on the relevant work of
group.
There's likely to be both in parallel because this fit different needs and different use cases.
Let's go over to authentication, so we all agree, passwords need to get rid of that.
They are based solution as use OAuth, and because it's a very widely deployed, however,
it OAuth works well if you have your mail servers provider, you have your OAuth server,
and you have your metmail, and you make that particular web mail work with your OAuth server,
and you optimize them together then OAuth first perfectly, if you have a mail client with
all the thousands of ISPs there, then OAuth has problems, I'm going to get into details.
The other alternative that we are considering is Paschis, if anybody has some other alternative
idea comes to me.
The main problem with OAuth first number, there's a number of configuration options that
the mail client needs to know in order for it to work, for example, it needs to know all
the URLs.
The clients need to be registered, the tokens expire, the login expires, OAuth is a framework,
not a protocol, even the RC says it's a framework, so it's not tightly defined, everything
is up to for a configuration, which is a problem for if you make it a standard, and we need
to fix that.
For the configuration, there's a number of solutions, so you need, this is the reason why this
doesn't work with your server, only Google, you're who in Microsoft can do use that,
because it's all hard-coded, there's solutions for that, there's a well-known URL from
OpenIVConnect, there's an IFC with another well-known ID, which is also pretty much just
the same thing, it's a different URL, but pretty much the same content, and you can also
use all the config, like I just showed earlier, so there's solutions for that.
The other problem with OAuth is the client registration, and that's a very fundamental
problem, and if you want to talk to an OAuth server, you must have a client ID, otherwise
you're not allowed to connect, and the client ID is no more specified in the OAuth spec,
how you get that, in the reality is you have to register with Google, you have to register
with Microsoft, you have to register with Yahoo, in reality, with Yahoo, I have to sign
a contract, and there's very nasty terms in the contract, and I'm not allowed to tell you
why they're nasty because they forbid me to tell you what's in the contract.
With Microsoft, they gave me the run-around for two months, I had to become a partner
for them, fill our tons of forms, which didn't even work, had to contact the support,
and they admitted, yeah, this is not working, sorry, and with Google, I have to make a
paid audit with a third-party company, which costs a lot of money, and I have to do that
every year.
So that is inherently bad.
Microsoft is a direct competitor with me, like they have Outlook as an application, I have
a different email application, I need my users to be able to connect to Office 365, and
to Outlook.com, otherwise, I'm not an email client, if they can do that, and so we are
a direct competitive situation, and they make my life hard, so for me, that's clearly
anti-competitive behavior, at least it feels like that to me, and is also directly against
the idea of open-source, because I cannot just fork a client, and distribute that under
my own name, because I'm not supposed to use a client idea of Thunderbird, right?
So I need to register all these myself, which makes it really hard, I can tell you it
takes me three months of work, you don't want to do that, so it basically makes it impossible
to fork in practice, right?
You can do it as to much work, so it's not a good idea, and the main problem is you
have 100 email clients, you have 1,000 providers, and you multiply the registration,
so you have 10,000 registrations, it doesn't work in practice.
The other problem with OAuth is, is it inherently depends on the web browser, so as a mail
client, I either have to have a web server embedded, or have a web server embedded, I have
the two choices.
If I want to launch the browser, I have to somehow get back to me, so I don't like that,
I mean, it's doable, I don't like it, but the real problem is that everything that
happens in that little box there in the web browser is complete black box for me.
If user comes to me, a user comes to me and says, hey, my login doesn't work, and I have
no way to debug that, because I don't know what's happening in that little browser frame
there, so, and I don't have an account at the company that he has in all the problems
are specific to that company or that doc, and I cannot debug that, and I cannot help
this people, and they just come to me does work, and I say, yeah, not my fault, and this
is the end, and I lost this customer, so I cannot support my customers, and that is not
an acceptable situation.
I can put in a lot of work to make Google, and maybe the standard Office 365 and you
who more work, but like I said, it's cost a lot of work, but I cannot make full of them
work, it's practically impossible.
So there needs to be more transparent, I need to be able to have some way to debug this.
Expire is a problem, like I said earlier, if my mother sets this up, she expects this
to work, not just break after two months.
Error handling too, I just said that, like, if something fails, I don't even know why it failed,
it could be that the user just decided to app board, it could be that he couldn't log in,
and I don't even know, or maybe forgot his password, and I cannot distinguish whether
the user forgot the password, or he hit a problem, or his administrator just disabled
that, and I cannot find out what the problem is, and if I don't know what the problem
is, I cannot fix it.
So that's the reason why mail clients today still use password, because of all these problems
that I just mentioned.
Password is a simple protocol that's very defined.
I send the username, I send the password, if they both are incorrect, I can log in.
That's not the case for OAuth, and this is the reason why we're in this problem, and
we get to fix those underlying problems, a recognized that they're there, not everybody
even recognizes that we have a problem with OAuth, and then we get in agreement how to fix
them, and we are not there yet.
So there is a proposal out there for that's currently, I think it's adopted by the mail
management, IFTF working group, that's a proposal from fast mail, how to do this.
So what they're saying is, okay, we take OAuth, and then we take the dynamic line registration
to take care of the client ID thing, and then we specify the scope, how they're supposed
to look like, because they're different for every mail provider, so let's name a low-down,
and then they're nailing another, that I need to get a refresh token, I need to get a whole
expire time, all this list of loosely defined and OAuth, this defining it more precisely.
So that's an attempt to do that, if everybody adheres to all of that's in there, then the
problem could be working with the caveat that if something goes wrong, I still can't fix
it, because in the rep route, but otherwise it should theoretically work.
The problem is the should, because a lot in this document is should, so it doesn't have
to do it, and if, as a client, I still have to handle that case and then things don't
work and so on.
The other problem is, if we accept that this is okay, the OAuth stuff, then there is a ton
of ISPs who are going to say, yes, I'm going to do all of that, but I'm not going to do
like dynamic line registration, you still have to come to me in register.
So that is very likely to happen, I think, a lot of the big ISPs are going to take that
stands, and then we still have the problem that we have today.
So I have a really bad feeling about this, but in theory, that should be working.
This is an internet draft right now, this is under discussion.
If you have an opinion about that, if you're free to post to the mailman mailing list on
the IFT, and the IFTF.
Another alternative from me, that's probably not going to fly, but it was my idea to just
disable the client ID by just cartconning it to open, and if an ISP wants this to work
with my outlines, they have to accept open as client ID, and if all the my outlines just
send open, then the ISP has a choice, either he allows my outlines with open or he doesn't.
But everybody has to agree on that, that we do it this way, but doesn't seem to be the
case, I don't know, we'll see.
The other alternative that we have is pass keys.
So what we're doing right now is we are proposing an Sassel standard, Sassel is the
lock-in mechanism for IMF S&TP and pop-free.
We're proposing a Sassel wire format, how you can use pass keys with IMF and S&TP and so on.
One problem with that is when the lock-in, we need some free implementations for that,
and then you do help for this.
How does Sassel pass key work?
So he is the URL for that proposed standard, the way it works is you would be working is
you go with your web browser, you go to your ISP website, in your account, in the security
settings, and you say here I would like to create a pass key, in the same way that you do
it on GitHub right now, where you add a pass key there, you would do the same thing on your
ISP's website, you create the pass key, your browser contacts your authenticator that you
have on your operating system, whatever that may be, and the authenticator creates a pass
key, the returns the public key to the browser, he sends it to the website, the website
register that.
Then the mail application would have to access that same authenticator with the same
store of pass keys, so when it does the lock-in, it says Sassel pass key, and then the server
sends a challenge to the client, and the client would then mail the main client would just
take that challenge, rub it in and pass it on directly as it is to the authenticator
or the pass key manager if you want, and that one then would show your lock-in, you can
either do a fingerprint or the face ID or your device lock, or the device unlock thing
that you do, the pin, whatever you're using, and then the authenticator allows the signing
with the pass key of this challenge, it signs that challenge with your pass key, once this
completed, sends it back, your mail app takes it verbatim and just pass it forward to the
mail server, and the mail server then verifies that against your pass key, the public key,
sees whether the site's nature is correct, and if everything is good, you're locked in
all is good.
There's one problem, and that is there's a fairly good agreement that this is a good
way to go forward, there's one problem with that, you don't want to put your fingerprint
every time your mail client opens an IMF connection, because that happens all the time.
So how do we do that then?
There's another proposal for a sassel, remember me, which is something that you do after
you lock in with your pass key, you say, remember me, the server returns you a token, and
the mail client saves that token the same way what save a password, and the next time
it wants to connect with IMF, it just takes that token and it says sassel, remember me
with that token, the server gets that token, sees, okay, that token is valid for that
user, okay, you're locked in.
So that's the non-interactive lock-in path, and that can then work afterwards, either with
the next connection or tomorrow or in a week or whatever, and this token can be anything,
this is completely up to the server, what it uses as a token, it could be a JWT, it could
be an O-auth refresh token, it could be just a random string that the server saves for that
user, for that user account, it's completely up to the server how it wants to implement
that.
That password, that you create on the author, whatever.
This one big gap for a pass key is right now, and he has a plea for you or for any of your
friends who are looking for a great project, because this is a big need right now.
I'm using a Linux desktop, and there is no operating system level authenticator, a pass
key manager for the operating system.
We have the bitboard and key pass exceed, but they're browser add-ons, they work only
in a web page, because they're hooking up into the web page and hijacking the web APIs,
but it's not going through the browser, so I can either use this manager or my hardware
token, but not both at the same time, and it's not going through the browser, and so
it would not work with this proposal.
And it would work on Windows, on Macon, as on iOS, on Android, there is operating system
level authenticator, some pass key managers.
Unfortunately, those are tied to the vendor system, so I need, on Android, I have to have
a Google account in order for pass keys to work.
And for me, that's completely unacceptable, I don't do that in a cannot use pass keys.
So I would like there to be some open standard, some standard API, it's just like four
C functions, it's completely trivial and simple, and just to get a pass key and create a
pass key, it's very simple, but somebody needs to define that API and build some implementations
for it to save these pass keys, generate them, sign them.
So could somebody please build this standard API for Linux, it makes some implementations
so that can select which authenticator I want to use, and then build an actual authenticator
so that Firefox has an API to call, because on all the platforms, for example, it's
a part from Linux because it's not there, and on Android, I also need some choice.
So somebody, please, we need to help with this to implement some pass key managers, only
Linux, and the other platforms.
That's it, so any question.
So I realize this is very controversial topic, so maybe if you'll build a lot of temperature
raised, if you've made two questions, sorry for that, please raise them to us some questions.
Yeah, I mean, you went up, first of all, now a very technical thing about the
successful pass keys, they're supposed to be down to the main, right?
Correct.
So sorry, he's saying the successful pass keys are supposed to be bound to a specific domain,
the combination of user account or domain, so I can not reuse them on some other domain
which is a security feature, it's intentional like that.
So I'm wondering how this is going to work for me, for my web, my mail server, I have a web
mail interface, so does it mean that the exact same host name, or if that's for you during
I-net, for I-net?
You've eat the question?
He's asking whether the web mail host name has to identical to be with the I-map host name
in order for the pass key to match.
I believe that's up for the definition of the client, so it doesn't have to be like that.
We can specify that, we could, for example, say it needs to be the same domain, top level
domain, but not the same host name.
This is still up to-
So if the browser, if you're in your browser, you're on your web mail, you're registering,
for example, you're on mail.mox.de.
I'm not 100% certain whether it does the domain, top level domain, only all the host.
I have to look that up, but then the mail client would be the one that's selecting the name, so it can define that.
Does it good question?
Yes, Michael.
You shouldn't have to repeat the question.
No, it's in front of the microphone for the video.
Not as surprised to see here that you don't like, for the whole observation, we don't like the fact that somebody
has stopped happening to the HTTP web browser world.
But you seem to be okay with that.
Someone has stopped happening in the pass key world.
How do you reconcile those two positions?
You're saying that I have a problem with the HTTP.
I'm just repeating the question.
I'm just repeating the question, okay, for the video.
So you're saying that for all of, I have a problem with HTTP web browser, but I don't have that problem with pass keys.
The difference being that in this sets of pass key thing, there is neither any HTTP, nor any web browser involved.
For the record, I have no problem with HTPS.
I have a problem with the HTML, whatever is happening in the browser stuff.
But in the system, there is no HTTP involved at all from the main client.
You have to register that pass key sometime in your browser.
But that's one time thing, and then the main client is not involved in that.
The main client never opens any browser window.
But there's still the dependency at some point you've made on this registration.
Yeah, we're not going to make it.
We're not going to make the web go away, and we don't want to.
But it's just in the log-in sequence.
We don't want to depend on that and the log-in sequence.
Does it make sense?
I don't understand, but you're saying it's still a dependency at some point.
It's not necessarily on my device.
I can do that on my desktop.
I can register on the desktop.
The key can be synced to my mobile, and I can use the same key.
Pass keys can be synced.
If you don't chew, that can be synced here.
Any other questions?
Aren't?
Yes, you had a question.
Not really, I have a comment.
Okay.
There's still a dependency.
The point is to make that dependency.
The dependency on variety of the web that's less hard to debug.
To get rid of the kind of dependency that's hard to debug.
Not because it's hard to debug.
It's more about the fact that the user is probably already a registered.
Like, the user is that one to use that.
That probably already have a pass key.
Or that might already have a pass key in this in the set.
So the main client can just use that.
And it doesn't have to be specifically registered for the mail application.
Or, yeah.
Are there questions?
All right.
Sweet.
Thank you again.
Thank you.