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

"Paul E. Jones" <paulej@packetizer.com> Mon, 08 February 2016 00:44 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901981A8733; Sun, 7 Feb 2016 16:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.993
X-Spam-Level:
X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWbhYlT0_Kzv; Sun, 7 Feb 2016 16:44:54 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279921A8732; Sun, 7 Feb 2016 16:44:54 -0800 (PST)
Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u180iqa6014083 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 19:44:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454892293; bh=9sABXvTC2p/ZRAkqSmHdXkXDjTtqsb5daTRhd8ZFqwg=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=N05eDZMyPqK/Jz6EPdDQTwgDTy+zgSxw3JkaBmtSqKRvM3XJcBxzTGrIPhpv99k9C AGOyWLXSnA7JX1QtxLSmzKSrOd4FVj/ZN09geZnBL3tD3nC9zhjpkT1xS5l4JwRvcn f/fgIAxqsK74DWSR36zHBPPPAKuaX6Gik1cb+iPQ=
From: "Paul E. Jones" <paulej@packetizer.com>
To: John C Klensin <john-ietf@jck.com>, apps-discuss@ietf.org, webfinger@ietf.org
Date: Mon, 08 Feb 2016 00:45:20 +0000
Message-Id: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney>
In-Reply-To: <EE5D283AC957E10DA443AA15@JcK-HP8200.jck.com>
User-Agent: eM_Client/6.0.24316.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.14 (dublin.packetizer.com [10.109.150.103]); Sun, 07 Feb 2016 19:44:53 -0500 (EST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/GRPQjyIb0HnLmorVdJe1hXYg-W4>
Subject: Re: [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 00:44:56 -0000

John,

>>  When we undertook the work on WebFinger, one of the use cases
>>  we had in mind was the ability to allow an email client to
>>  automatically provision itself.  What we wanted was for a user
>>  to be able to enter an email address and password and for the
>>  email client to be able to determine via WebFinger exactly
>>  what protocols to use, what ports, the name of the SMTP
>>  server, and the name of the POP3 or IMAP server (or both).
>>...
>>  Still, I personally am frustrated with entering configuration
>>  data into my mobile phone, tablets, desktop, and laptop every
>>  time I install a new email client or get a new device.  It's
>>  only made worse when I have to repeat the process for every
>>  member of the family.  So, I'd really like a solution to this
>>  problem.
>>...
>>  RFC 6186 exists and it addresses much of what I want, though
>>  client support is lacking.  That begs the question of "why?"
>>  Would defining something that builds on WebFinger encourage
>>  client developers to add support?
>>
>>  A couple of issues with RFC 6186 are:
>>     1) Information about services is exposed to the world and
>>  some prefer to not expose the names of servers, ports,
>>  protocols, etc., especially internal ones to a company
>>     2) It does not allow for user-specific configuration: the
>>  entire domain is set to use the same information
>
>Paul, I wonder whether it is time to revisit ACAP.  Its
>predecessor, IMSP, was specifically designed for the types of
>email cases you describe and it and/or ACAP were supported in a
>reasonable range of mail clients.  Use of a 6186 mechanism to
>locate an ACAP server that required authentication (and, where
>appropriate, user identification so different information could
>be delivered) before giving out information would seem to
>mitigate the two issues identified above and use of an existing
>protocol (DHCP might be another candidate but has, IMO, never
>really taken off for application-layer client configuration and
>has issues when used across WANs on the public Internet).  It

I'm not opposed to revisiting anything, but what will it take to see 
something actually deployed?  ACAP is not a trivial protocol and it's 
scope is broad.  I'm not even aware of any client implementations today 
and I've only seen some historical server implementations.  Nonetheless, 
I'm not opposed to any solution that people will actually get behind and 
make happen.

I would not recommend DHCP, because this is useful for hosting 
providers.  It's even not very useful for many enterprises, since not 
everyone is behind the corporate firewall.


>seems to me that upgrading something with which we have
>significant experience might be a better alternative than
>deciding Webfinger is the latest hammer with which to hit all
>nails, especially nails that are not specifically web-related
>and that such an approach might be more easily accepted.

WebFinger is merely a defined place to go query via HTTPS to get a JSON 
object that contains pointers to whatever data we're seeking, along with 
a specific syntax for what those pointers look like.  Most of the world 
has infinitely more experience with an HTTP GET request than virtually 
anything else and processing a JSON object is a pretty trivial exercise. 
  WebFinger is used for a few applications, though in only one standard I 
know at present: OpenID Connect.  So, it's not quite the hammer you 
suggest it is.  However, it was designed specifically for discovering 
information like this, not knowing anything but a "subject" and a 
domain.  Given we're just talking about a couple of HTTP queries, I 
think the barrier to acceptance is going to be lower than most other 
solutions we might devise.


>>  The idea is basically this:
>>    * User enters paulej@example.com into the email client and
>>  email password
>>    * Email client queries
>>  https://example.com/.well-known/webfinger?resource=acct%3Apaul
>>  ej%40example.com
>>...
>
>Given all of the discussions we have been having about security
>and privacy lately, if enterprises are, as you suggest,
>sensitive about giving out information about how they are
>configured, developing a new system that depends on email
>addresses as identifiers and passwords for authentication seems
>unwise at best.  Of course, ACAP would need examination and
>probably upgrading for serious security as well, but...

I am willing to bet that the majority of independent domain operators, 
hosting providers, etc. will continue to use the username/password 
combination for a very long time.  That said, WebFinger (by virtue of 
the fact it is nothing more than an HTTPS query) can use any HTTP-based 
authentication scheme we want, including certificates, 
username/passwords, or whatever else we night propose.  I only suggest 
username/password, as I have yet to personally encounter use of anything 
else.  Whatever solution we devise that replaces the username/password, 
though, will be supported in HTTP and, therefore, WebFinger.


>>...
>>  I'd like to hear your thoughts. Do others feel this could be a
>>  valuable specification?  Are there client developers
>>  interested in helping to solve this problem and willing to
>>  implement something here?
>
>Again, see above.  This isn't a strong pitch for ACAP, but is
>just a thought about the possibility of a well-known tool with
>which we have significant experience as an alternate starting
>point.

If ACAP was going to take off, I think it would have by now.  It did not 
and I doubt it will, but I'm absolutely not opposed if we were to 
somehow get a bunch of major client developers on board.  We'd need some 
server software that is well-supported, too.  We either have to resign 
to the fact that it's not going to solve the problem I think we should 
solve, that nobody cares to solve this problem, or that we need 
something simpler (e.g., a couple of HTTP queries to get config info).

Paul