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

Dave Cridland <dave@cridland.net> Mon, 08 February 2016 08:42 UTC

Return-Path: <dave@cridland.net>
X-Original-To: webfinger@ietfa.amsl.com
Delivered-To: webfinger@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B521ACDA4 for <webfinger@ietfa.amsl.com>; Mon, 8 Feb 2016 00:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.368
X-Spam-Level:
X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
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 Weuymou_jeMt for <webfinger@ietfa.amsl.com>; Mon, 8 Feb 2016 00:42:00 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAAE1ACD9B for <webfinger@ietf.org>; Mon, 8 Feb 2016 00:41:59 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id p63so102334105wmp.1 for <webfinger@ietf.org>; Mon, 08 Feb 2016 00:41:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XaoGp6F6Vpjyv9pV1D8RU9/NrvwV2NEwt7qKJYzXhvI=; b=RIlNrIdyQc06aevnjetWKAjij7jrYHZDj9RinzPWwmE0HCiOxlLyDsBJfofsLwaEfj uPt2E86arCqbM56VEwLFNZ1ieKcf5qzyvZ1FcieEnoDP1vGpo3qti3VNtsAV/tOoTPlP 0Fvv72EhoZZWF4bu5szqVBTfCctwEH6R/QOVQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XaoGp6F6Vpjyv9pV1D8RU9/NrvwV2NEwt7qKJYzXhvI=; b=mGLFCICrkGEJz4TXw+htffioeCqLR4/Z3CdlO90aLH0kp8L/VTmLr2seSW2lgbjVPu d5PRBfDv+UB7ZAhA+gcOPGzRHEsV3oqZkmwAbBmVTCKIVEkwAUsJ8nVsKFxj4LFod89K ZzI6XlFGQOX7AcjIU64CJ4j5eKVat5JV79bj2jRD4Q2crlKirZQ44bPqZv2GQcTTNgoC 9erf4vT2Cvz+Bgd3dTz6WlHcEtC4tIFWVnZnf4GmvLoGwm+wJgHlx2bNBQncmj8BYWLW klUkCcjH37OrblEI6ZqdZVWVDb5hylJ/bmUL3Ne0xRKZ5GrHDO5pg/L6C8dcLbmCisym V2BA==
X-Gm-Message-State: AG10YOR6gL0qwYo52dsuwJv8+/fXTptAB3ZdNbL/cBukQGlmJM7eDfBbp2wHZBwtoJ7qaQ/N9oYBwUl++ZswjH7N
MIME-Version: 1.0
X-Received: by 10.28.30.198 with SMTP id e189mr28057362wme.60.1454920918231; Mon, 08 Feb 2016 00:41:58 -0800 (PST)
Received: by 10.28.47.151 with HTTP; Mon, 8 Feb 2016 00:41:58 -0800 (PST)
In-Reply-To: <EE5D283AC957E10DA443AA15@JcK-HP8200.jck.com>
References: <em72874602-962e-43e1-90d2-497acacceffd@sydney> <EE5D283AC957E10DA443AA15@JcK-HP8200.jck.com>
Date: Mon, 8 Feb 2016 08:41:58 +0000
Message-ID: <CAKHUCzz1xCsaPmnq-eAw6c9TMTdeHuQNTEjgGwDt4Uf8q2LAYQ@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: John C Klensin <john-ietf@jck.com>
Content-Type: multipart/alternative; boundary=001a114b33de820c33052b3e2c83
Archived-At: <http://mailarchive.ietf.org/arch/msg/webfinger/PhKG-3bAEbUN_QMLokrXPAjLnLo>
Cc: "Paul E. Jones" <paulej@packetizer.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, webfinger@ietf.org
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webfinger/>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 08:42:02 -0000

John,

I suspect that in this space, we run something of a risk of assuming the
question is which hammer to use rather than deciding what nail we have.

I'm mildly amused that criticisms of RFC 6186 are around exposure and
per-user configuration, since I've never seen either be a problem - but we
could, of course, declare these vital requirements. As a relative newcomer
to email, having only spent a couple of decades on the subject, even I am
well aware that there are as many niche requirements as grains of sand, and
no solution will ever encompass them all.

Instead, there are two extreme approaches we can usefully take, and there's
middle ground as well:

a) We prescribe a sane configuration.

The MUA, given an email address, can programmatically determine the servers
and authentication details without using the network.

b) We define a discovery solution.

The MUA uses network services to locate the servers and authentication
details.

An example of the middle-ground would be that we say servers should be able
to use an email address as an authentication identifier, and that all
services should use the same credentials, and that RFC 6186 records should
be used for discovery. I think that just by adding RFC 6186 records, the
vast majority of services will immediately work. (Many MUAs performing
ad-hoc discovery essentially synthesize 6186 records where the MX is
recognized, after all).

If you want more, you'll need to add more infrastructure, and the costs
here are quite high - especially since you need not only a new service at
the server end, but changes in every client.

There are, in existence, XCAP, ACAP, IMSP, and WebFinger in this space.

You could also usefully add XMPP into the mix - it's never had problems
with server discovery, the addresses and authorization identifiers it uses
are compatible with the vast majority of email addresses out there, and it
can provide a pub-sub based arbitrary data storage via its PEP
functionality which is well deployed.

Which one to use doesn't depend on syntax - though that might be, of
course, a tie-breaker - it depends on exactly what user-experience we want
to deliver.

Dave.

On 7 February 2016 at 23:13, John C Klensin <john-ietf@jck.com>; wrote:

>
>
> --On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones"
> <paulej@packetizer.com>; wrote:
>
> > Folks,
>
> > 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
> 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.
>
> > I'd like to suggest we tackle this one narrow email
> > provisioning problem using WebFinger, but want to get feedback
> > before spending time drafting a formal proposal.
>
> See above.
>
>
> > 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'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.
>
>      john
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>