Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger

["Paul E. Jones" <[e-mail]>]

Marten,

I would truly love to see this move forward and have had an intention of 
writing a draft myself.  I'd be happy to collaborate with you on one.  
Just in the past couple of weeks, I had to help somebody set up their 
email client remotely to use an IMAP server.  It was incredibly painful 
for me to try to step them through the process not having access to 
their screen, etc.  After that experience, I'm even more convinced that 
a solution to this problem is needed.

I personally don't think learning the existing of an account is an 
issue, since I can discover that by merely sending an email.  However, 
if that is a concern, then the simplest solution is for the server that 
is providing the configuration document to requires authentication 
regardless of the user ID presented.

If I were to deploy this in my own environment, I would use the same 
user ID and password to retrieve the configuration document as is used 
to log into the IMAP for SMTP server.  Interfacing with the auth 
functions that already exist would be fairly trivial.  I don't fully 
understand why we would want to have a different authentication 
mechanism, given that (at least in every case I've seen) the IMAP/POP 
and SMTP services generally validate users from the same authentication 
functions behind the scenes.  Sending credentials over HTTPS to a server 
to then validate in the same manner seems to make a lot of sense.

So the solution I had in mind would be to query using WebFinger to get 
the usual output for "[e-mail]".  In that JRD that is 
returned would be a link relation type "mailconfig" that refers to  a 
resource like https://dublin.packetizer.com/mailconfig/?user=paulej.  
That web interface would require just basic authentication (since the 
password would be encrypted with TLS) and authenticate with the auth 
function like the other mail services.  If auth is successful, it would 
return the JSON structure that would contain the mail configuration 
information.  I could easily have something like that working very 
quickly.

I'd be very hesitant to introduce more complex authentication or 
identity procedures, personally.

As for the content of the file returned, while I very much think we 
should only be using the latest security procedures, we have to allow 
the document to return things like "use SSLv2" if that is indeed what 
the IMAP server supports.  These policies are really for the IT folks to 
dictate and I don't think the document we produce should dictate the 
security mechanisms.  It's really the place for other documents to 
dictate best practices and any suggestion we might make might be wrong 
in 5 years. :)

That said, I'm certainly favorable to simplicity and have no strong view 
on exactly how the config information should be structured.  I wrote up 
an example https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-03 
that was overly trivial.  It did not consider the possibility that a 
client might have multiple protocols, for example.  I think it is 
important to provide a JSON document that is an array of mail 
transmission options then an array of mail retrieval options.  Within 
each array, I would expect an array of configuration options ordered in 
the preferred order of the administrator.  Thus, the preferred security 
procedures can be conveyed.  So, "IMAP" and the host might be listed a 
few times with different ports and transports (SSL and TLS and, gulp, no 
security).  I have seen some services offered where the host name 
actually differs based on one's geographic location.  Thus, multiple 
servers names might need to be conveyed, along with perhaps checking the 
physical location of the user.  (But, that detail doesn't have to be a 
part of the spec.)

Importantly, since the whole process can be automated, then it is 
entirely possible for the client to re-check the recommended 
configuration information from time-to-time to see if there is a change 
in the configuration details.

Paul

------ Original Message ------
From: "Marten Gajda" <[e-mail]>
To: "Paul E. Jones" <[e-mail]>; "[e-mail]" 
<[e-mail]>
Sent: 6/1/2016 9:59:58 AM
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via 
WebFinger

>Hi Paul,
>
>we've brought up this topic during the last CalConnect conference and 
>it
>was decided to revitalize the TC where the draft you mentioned
>originated from. We have some interest from software vendors and users
>to get this solved.
>
>As mentioned before, one of the major problems to solve is
>authentication. The issue raised was that the pure existence of a link
>to a configuration document in the webfinger response can reveal the
>existence of the account. On the other hand, requiring authentication
>for auto configuration results in other possible security issues and a
>poor user experience. The latter ones could probably be solved by 
>making
>OpenID Connect a requirement for auto configuration, which, on the 
>other
>hand, adds another layer of complexity and probably makes it less
>attractive to smaller vendors.
>
>Does anyone see any possible solution to that?
>
>I'd also like to suggest a few changes in the structure of the
>configuration document and to drop support for services not protected 
>by
>TLS or any other transport security layer. I'll post an updated draft 
>as
>a basis for discussion.
>
>I'm happy to join the upcoming IEFT meeting in Berlin and have a BOF or
>something if there is enough interest in that.
>
>cheers
>
>Marten
>
>
>
>
>Am 09.02.2016 um 02:03 schrieb Paul E. Jones:
>>  Marten,
>>
>>  Thanks for the encouraging words; it sounds like you understand the
>>  problem that needs to be solved.
>>
>>  I always felt the server side was the trivial part.  As you said, 
>>it's
>>  possible to set up a simple WebFinger server with a static file (or
>>  sets of files), an .htaccess file, etc.  I use a server that pulls
>>  data from a database, myself.  Importantly, though, the WebFinger
>>  protocol is very simple (and I have to thank a number of folks who
>>  forced that simplicity), so I see the server side as being far less 
>>of
>>  a barrier.  Hosting providers, for example, could very quickly and
>>  easily support this server-side.
>>
>>  The clients are the challenge.  As others have noted, this requires
>>  code changes in the clients and deployment of the clients.  I'm
>>  encouraged that you're working on client code. :)
>>
>>  Having an RFC is going to be an extremely important step to actually
>>  seeing this problem solved.  That said, I did not want to spend time
>>  on something that would be met with total rejection.  It sounds like
>>  there is at least enough interest to start a meaningful dialog, so
>>  I'll try to put together a draft soon and we can go from there.  If
>>  you're interested to collaborate on that, you're certainly welcome.
>>
>>  Paul
>>
>>  ------ Original Message ------
>>  From: "Marten Gajda" <[e-mail]>
>>  To: [e-mail]
>>  Sent: 2/8/2016 5:54:58 PM
>>  Subject: Re: [webfinger] [apps-discuss] Mail client configuration via
>>  WebFinger
>>
>>>  Hi Paul,
>>>
>>>  as a client developer I'm very interested in this topic. We've
>>>  actually implemented draft-daboo-aggregated-service-discovery-03 and
>>>  there is at least one groupware server product which also supports 
>>>it.
>>>
>>>  While working on our implementation we've identified a few minor
>>>  issues with the latest draft and we've already discussed them with
>>>  Cyrus. I think most of these issues are solved easily.
>>>
>>>  Though, the major issue has not been addressed yet. It's the issue
>>>  mentioned by Stephen. Under certain conditions a client might have 
>>>to
>>>  ask the user upfront to authenticate, which may disclose the user's
>>>  credentials to the wrong service.
>>>
>>>  We didn't release this feature in our generic CalDAV/CardDAV 
>>>clients,
>>>  mostly due to that issue.
>>>
>>>  Anyway, I think it really starts with the server developers.
>>>  Implementing the current spec is not that much work on the server
>>>  side. In many cases the server configuration document could just be 
>>>a
>>>  static file and setting up a simple WebFinger end point is not that
>>>  hard either. Actually, for our corporate server we've just created a
>>>  few static files and some redirect magic in our .htaccess file to
>>>  provide the WebFinger stuff.
>>>
>>>  On the client side it's more work, because it affects the account
>>>  setup flow a lot. But it surely is worth the efforts if more 
>>>services
>>>  support it.
>>>
>>>  However, before even the server developers can start, it requires an
>>>  RFC. So lets start to think about how to solve the authentication 
>>>issue.
>>>
>>>  cheers
>>>
>>>  Marten
>>>
>>>
>>>  Am 08.02.2016 um 20:00 schrieb Paul E. Jones:
>>>>  Cyrus,
>>>>
>>>>>  Right now it is not clear to me that an ASCOT-like solution would
>>>>>  be adopted given the use of device management. Before embarking on
>>>>>  this we need to take a careful look at whether any solution is
>>>>>  likely to be adopted (with the biggest burden likely being on
>>>>>  clients/OS vendors to support it). Given the device management
>>>>>  solutions already out there, I suspect there would be little value
>>>>>  to m,ost of those folks to actually support ASCOT.
>>>>
>>>>  I completely agree that we should try to get a sense of the
>>>>  likelihood of success.
>>>>
>>>>  Within the enterprise -- especially the larger ones -- you are
>>>>  entirely correct that device management systems provide a good
>>>>  solution for most of the employees.   However, I interact with a 
>>>>lot
>>>>  of smaller businesses that do not use such systems.  Many of them
>>>>  have a web hosting company host their domains and do not have IT
>>>>  staff to help them on a daily basis.  I'm skeptical that a device
>>>>  management system would help that class of users, so arming hosting
>>>>  providers with tools they can deploy to their customers would help,
>>>>  I think.
>>>>
>>>>  There are also a number of individuals who have their own domains,
>>>>  many hosted on the many, many web hosting providers out there. Same
>>>>  issue for most of them.
>>>>
>>>>  So, I think there is a market need.  I suspect if we were to create
>>>>  a solution, hosting providers were to deploy it, and client
>>>>  developers were to support it, people would use it.  However, 
>>>>that's
>>>>  a string of "ifs".  I think it starts with the client developers.
>>>>  If there were people interested to solve the problem, I think the
>>>>  rest falls into place.
>>>>
>>>>  All that said, if client developers are uninterested, there's 
>>>>little
>>>>  point working to solve this problem.
>>>>
>>>>>  As an alternative, the IETF might want to take a more serious look
>>>>>  at the overall device management solutions, and see if there might
>>>>>  be scope for standards in that area. That would allow us to build
>>>>>  off something that is already deployed (in a number of proprietary
>>>>>  solutions) but is today solving the problem of account setup.
>>>>
>>>>  I think your suggestion is worthwhile independent of whether we
>>>>  solve the problem for smaller businesses and individual users of
>>>>  hosted domains.  It would good if the same solution or would 
>>>>address
>>>>  those needs of smaller businesses and individuals, but if it 
>>>>didn't,
>>>>  it's still a step forward.
>>>>
>>>>  Paul
>>>>
>>>>  _______________________________________________
>>>>  webfinger mailing list
>>>>  [e-mail]
>>>>  https://www.ietf.org/mailman/listinfo/webfinger
>>>
>>>  -- 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
>>>
>>>  _______________________________________________
>>>  webfinger mailing list
>>>  [e-mail]
>>>  https://www.ietf.org/mailman/listinfo/webfinger
>>
>
>--
>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
>
>_______________________________________________
>webfinger mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/webfinger