Re: [art] Auto-configuring Email Clients via WebFinger

[Marten Gajda <[e-mail]>]

Am 19.07.19 um 15:33 schrieb Steffen Nurpmeso:
> Marten Gajda wrote in <[e-mail]>:
>  |As a client developer, I want to provide a smooth UX to our users. \
>  |This means I need much more information than just a server URL.
>
> You want to present them a barcode that they can scan with their
> smart phone and which is made available via some local registry to
> any interested application (via some kind of IPC, say DBUS), then.
Sure, but that provisioning part, which also contains user specific data
(e.g. account name or maybe even credentials), should be a separate
standard. Also, you don't want to share account data with "any
interested application". I'd prefer if the setup component checks the
system (and optionally the app store or software repository) for
applications which can handle the protocols in the service configuration
document and asks the user for which ones to provision with the
configuration and access tokens
>  |For instance, I also want to 
>  |
>  |* present the name or logo of the provider which hosts the user's account, \
>  |ideally before they enter their credentials,
>
> You made a contract with a provider, and it has given you
> credentials to use.  The provider has an IP address, and you have
> submissions, pop3s and imaps access.  On the web site's welcome page
> the services URLs were noted.  (Let's say imap.XY.Z.)
So? The idea behind an auto-configuration or service-discovery is to
avoid having to type any URLs into client applications. Also I'd expect
the client to rerun the discovery every now and then (for instance when
the cache expired) and pick up configuration changes (like newly
supported services).
>
>  |* provide links to support channels, reset password pages, account \
>  |management,
>
> Ha!  If it were that easy to find these pages on the web site of
> your provider!!  Shiny happy people there will be, i bet.

I'm not sure how to understand this statement. If you suggest that some
service providers deliberately "hide" password reset and settings pages
to present more ads to the user and they wouldn't be interested in
providing these shortcuts, you may be right. But many providers still
value usability and user experience, not to mention all the other
non-freemail providers and use cases (like corporate services). Maybe
you just have the wrong provider.

If that's not what you suggest, please be more specific.

>
>  |* know the OAuth endpoints, if available,
>  |* know the OpenID Connect endpoints, so I can register my OAuth client \
>  |dynamically,
>  |* know the OAuth scope tokens I need in order to access a service,
>
> I personally have problems with OAuth.  Not because of the
> standard group split, but mostly because you have to go over
> dedicated web sites (likely), granted, today without advertising.
> You can also go over onion to avoid IP-based location tracking
> (maybe, still), i develop fears this may not legally be possible
> anymore in a not too distant future.  (I do not use onion.)
>
> It would be nicer to have a client certificate (with password,
> possibly), that can be very easily refreshed/replaced, maybe as
> part of normal TLS payload, through whatever protocol i am
> currently connected to my provider, may it be SMTPS, IMAPS, POP3S,
> (HTTPS).  With a master account key.  And the possibility to
> revoke the old client certificate and refetch a new one simply by
> establishing a normal TLS session followed by a normal login with
> that key.  You can diverse that and use diverse client id, client
> secret and an access token.
>
> I just have implemented OAUTHBEARER for my MUA's SMTP, POP3 and
> IMAP parts.  While testing i needed the refresh token once an
> hour, and the client id, and the client secret.  So, once an hour,
> i need to load/decrypt the file which stores that triple.  It does
> not contain the account's master password, this is true.
> When i close the lid of my notebook i am protected, because the
> encrypted filesystem will then be automatically unmounted, but
> different to kdestroy(1) -A the token is still valid for some
> time.
You're off-topic. Anyway, you're welcome to propose a new standard and
I'd be happy to implement it once its ratified. For now OAuth2 is one of
the better options we have in terms of privacy and security. In general,
a service configuration protocol certainly should be agnostic to how
authentication is performed by the services. However, if the
authentication method requires the knowledge of certain endpoints they
should be provided in that document.
>  |* know which endpoints serve the same data via different protocols,
>  |* know *all* the available services (not just the ones I know about), \
>  |so I can suggest other clients which may be useful.
>
> Wow.  A different scenario.  You are the employee of a company and
> have been sent via airplane (which i would refuse to do, since
> airplanes are killers) to a different state/country, to another
> subsidiary of the company.  You are expected to login via their
> local net.  (I would wonder why they do not use some kind of
> company VPN, and if it is as simplicistic as via tinc.  But ok,
> i have no idea for one, and second the requirement to go over
> a local subdomain i could still imagine.)
Not sure what you're talking about.
>
> This points us back to the first paragraph.  Or the second.
> What is wrong with having the corresponding (A,AAAA,MX,SRV etc.)
> DNS entries for state1.company.xy and state2.company.xy?
> Add some more for logos (if not yet existing) or whatever.

For starters, not all Frameworks allow you to resolve anything but
A(AAA) records. On Java (and Android for that matter) it's not so
trivial to lookup MX or SRV records or even the current DNS server
address. A simple GET request to a well-known address, on the other
hand, is barely an issue. There may be use cases in which it may not be
possible or reasonable to set up a webserver just to provide that
document, for instance when a service only provides email. In these
cases we could offer a fallback mechanism which allows a client to
retrieve the document from another location, for instance by providing
an SRV record which points to the location of the service configuration
document. Other fallbacks may be possible as well, but .well-known would
definitely preferred.

> There is also that WWW paradigm of having a favicon.ico in the
> root of your web presence, it will be fetched up automatically by
> browsers, why can't you?

That's exactly what I'm proposing, allowing clients to get the
configuration for all services offered by a provider with a single GET
request to a well-known address (e.g. `/.well-known/services`).
Imagine the favicon.ico location would have to be retrieved by looking
up the "favicon" SRV record.

> You need to have A/AAAA for the web presence in the DNS, why can't
> you have MX / SRV for the other non-HTTPS services, too?

What's your point? You also need A/AAAA records for the non-HTTPS
services? You're comparing Apples and Oranges.

DNS is not suitable to provide that kind of structured information. One
of the reasons is that you only get information that you've explicitly
asked for, so you'd have to request every single bit of information that
you can use, without even knowing whether it exists.

> You want personalization on a per-user level, and you do not
> control your DNS zone, and you do not want to spend a little bit
> of money to get your own little DNS zone?  You would spawn a DNS
> server on your box to overcome this, but getaddrinfo(3) does not
> allow specifying which DNS server is to be asked?  Aha!  Yes, that
> is a problem.  You want to furtherly enforce decentralisation by
> moving responsibility away from the controlled and otherwise
> constrained DNS to anyway running "private" HTTP servers.  (A
> company could still have a VPN to overcome this, me thinks.)
>
> If it is because DNS is controlled and constrained then following
> the pigeon RFC there should possibly be an albatross RFC.  So that
> slow people like me understand the issue, finally.  There is
> mischief!  There is mischief!  I see more robots passing by that
> collect all the information stored in .well-known.

That's one more point for .well-known, if you ask me. Unless you have
your own private DNS server, all the SRV records are publicly available.
A service configuration document under .well-known can easily be
protected with authentication. IMO you should be able to retrieve a
redacted version of the document without authentication which just gives
enough information to know who you're talking to and how to authenticate
to get more info (e.g. by providing OAuth2 endpoints). There is no need
to disclose more information to unauthenticated users than you'd
disclose by setting up SRV records.

Hosting your own DNS zone comes at a price as you've just noted above.
You'll have higher efforts to maintain the server and you'll have to
make sure your client application uses the correct DNS server. So you'll
most likely have to enter it manually somewhere. This sort of defeats
the purpose of an automated service configuration.

In many cases a simple service configuration document can be hosted
statically. In other cases your server software (e.g. your Groupware)
could handle that for you. Maintaining DNS is not so easy and while TLS
encryption is almost trivial to set up these days (e.g. using
letsencrypt), DNSSEC is not that common yet
(https://stats.labs.apnic.net/dnssec).

>   I see people
> getting bombed because of information stored under .well-known,
> for nothing, who could they ask instead of a lawyer in that case?
Again, you can protect sensitive, non-public information with
authentication when using a .well-known resource. In addition a simple
document wouldn't have to contain much more information than you're
proposing to publish via DNS to the world.
>  |
>  |The attached example shows how a document might look like as per the \
>  |current status.
>
> The draft[1] contains examples.
>
>   [1] https://tools.ietf.org/html/draft-jones-webfinger-email-autoconfig-00

Yes, but my example doesn't use WebFinger and addresses a few other
issues. Have you actually seen it?

Cheers,

Marten

>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: [phone]
email: [e-mail]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743