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

[Steffen Nurpmeso <[e-mail]>]

Hello.

Please excuse the late reply, i try to get any quantum of clowd
free summer i can, not that much this year..

Marten Gajda wrote in <[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).

The barcode was a little irony; You seem to have in mind a totally
free world where you move in between say wireless networks and you
get automatically configured access wherever you are.
I hope i get informed and have to "ok" who debits my money, and
please let me wonder how this should work for anything but plain
transport providers?

 |>|* 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.

I was talking about user interfaces.
Take the city München who moved from Linux back to another vendor,
just like Wien did many years before that.  All voices i have
heard were not talking about technical problems.

 |>|* know the OAuth endpoints, if available,
 ...
 |> I personally have problems with OAuth.  Not because of the
  ...
 |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
 ...

There are more than enough in my opinion.  I am a supporter of the
strict separation of transport and protocol.  That is easy for me,
i came to the Unix world in 1999 and C in 2000, and by then
securing the transport was already a thing.

I am also a supporter of moving authentication to the transport's
security setup as such.  This of course already happens, and
i think as long as i can password protect all the contents of
client certificates this is ok.  Maybe that could be further
diversified (several passwords for different data; but of course
why not using multiple certificates).
Or a simple login- or plain text authentication thereafter. 

 |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.

I fail to see the need for moving away to something new.
I mean, if something lacks, you need a new resource record type,
i do not know whether there is one for corporate logos yet.

And if that is not flexible enough because you want to have IMAP
server A serving names from a-n and B the rest, and SRV does not
do that for you, then maybe two RFCs should be joined and a SRVT
record should be introduced as an indirection, and SRVT should
contain an URI template which a client application can use to get
to the real SRV that applies to it.

So that is my thought: why move away from all the established
mechanisms and invent something completely new, when all that is
needed to overcome the missing flexibility is that?

How can a JSON file be better than that?  Or is it dynamically
created when a user authenticates via client certificate, with
content exactly as desired for that user?  You surely do not want
to place a potentially infinitely sized file with contents for all
the users, so -- what could a JSON file under .well-known do
better than a SRVT with an URI template?

 |>|* 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.
 ...
 |> 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

That is definetely a problem for those frameworks, no?  I have no
idea of those, i left JAVA in Y2K, but i still have my JAVA
Programmierhandbuch by Middendorf/Singer around.

 |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

Is it still that easy with HTTP/2?

 |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.

I see this differently, and i tell you why.  I think it deserts
the infrastructure.  You have a thing here, and a thing there, and
all those parts move on individually and need to be tracked, and
of course administred, too.

For example, email.  From the three protocols SMTP, IMAP and POP3
the last one is deserted, no one ever cared that it requires
a really stable internet connection because if you loose
connection after doing twenty things the server will have
forgotten you did so.  And DKIM, DMARC and AUTOCRYPT were
introduced happily, massively increasing the size of message
headers, not updating POP3 to have a "body-only" command (even
though it seems trivial to add the counterpart to the "TOP"
command that anyway exists).

So i am post-office, look at the summary of old headers, and
decide that some of them are important even after hours, the
others not, what am i left with.  Granted that a more holistic
point of view is very hard, especially if so many parties are
involved.  But here it seems more about overall interest, this is
at least my impression.

 |> 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.

Well, yes and no.  That was very early, i think i already had
a favicon in 1996?  So to me this is web/HTTP since ever.
It would have been better to have a '<meta name="favicon"..',
then, maybe that even exists in addition?

 |> 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.

I actually do not understand this.

 |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 ask for auto-configuration, do you?  What shall be in that
JSON file you proclaim?  If it is more than something that fits in
a RR then what?  You need a naming scheme, an iterator, ... ?

 |> 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.

Again, what should be in this JSON you want to serve?
Is it personalized data then you need to have authenticated
yourself already -- for this you need to have an account?
If it is not personalized data then what is missing from SRV RRs
...  that cannot be provided by indirecting via some URI template
pattern from a hypothetic SRVT?

What is better, something completely shiny new, like a nice little
JSON document under a new .well-known URL, or a mechanism that has
seen iterations and evolved to something that addresses problems
discovered after having former iterations in use.
(I know the former is the answer, of course, as in rewrite in C++,
from plain text to XML, rewrite in rust, move from XML to JSON,
etc.)

 |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).

Oh, i am totally opposed to DNSSEC.  I would go for TLS/DTLS, and
i do not understand why the data cannot be signed with some TLS
certificate that can simply be looked up by doing a say HTTPS
connect to the zone's main address.

 |>   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.

Yes.  Exactly.  And i really wonder what should be the content of
that non-public version, and how it can be accessed, and even
more, interpreted.

 |>|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?

I had seen it by then, yes.

--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)