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

Phillip Hallam-Baker <ietf@hallambaker.com> Mon, 08 February 2016 19:56 UTC

Return-Path: <hallam@gmail.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 8D7A51B3265; Mon, 8 Feb 2016 11:56:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 FhJ0CscMrQ9Y; Mon, 8 Feb 2016 11:56:50 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 6F80A1B3263; Mon, 8 Feb 2016 11:56:49 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id l143so102615075lfe.2; Mon, 08 Feb 2016 11:56:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=n/cLDg1R2/MlflJKLZaHmYjL4l8ZSnwoBth69fCiqds=; b=GNw1w3m3kvzJgZIUDZ1Fbz4JTMBR2fxpuwOSoXTzxzcf+1eLFcsY614dqaH5gVwmuS QT2FQ3eDJAS2cB9bwbWGxmfYgF0HRJYJ+/Xgqz26BDFqp2naQufVYXHjUCBMlJeTJb5H moOa7SkiOjAUN7sozb7fjUAUKPd80Nx3dTuc0Mi0sriAMgpJv3rroEgcghvFGlvZybZp N/E4nQcAqD3gjhXRvoirZcGSiTlLyRmIB1gxWO65w172Izq4YzCHuytqy1GrTH4rHdb2 7/reGIyTvFgL/miRHSXv0czKCyEpsyGKWUwRSVPv2VFec8poEfXLk3uvFM6eeviJKy/P Kohg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n/cLDg1R2/MlflJKLZaHmYjL4l8ZSnwoBth69fCiqds=; b=fyVe+oALFx93MpzzWjDHU9CjrYVg5b2BYnyWCV8qPmYv3wCS5qSrDNxAzZWRp4wRRv 2H+/dtKqhGm/cRRdOtEElC8I/1tBHWM+SLBUsY126LxQsLkz0CRumLIYz4u7CV72cXlO 9ceKrfuLX5JgNHS4M1FYcoHUUI2eEV3lqCwTIeSgwBc12c2PXwKoV42J2A7xVXskubNi xyX1TmcV9sOHb8gHglq1eTKrKiNf2juFo2++jjS5QyAFFLnCGT5sU4GcxSrSStFa+T9x pseRI4xWcR4MPKQlb9UNfMu0JO2qWwWVIKjc6J5JKjcOTqlQFScrwbjlOxknNNVWMv41 zjDA==
X-Gm-Message-State: AG10YOShkXL48TK0uNLcbS2X4AoMAiDfeMOcEunAOBr0dzTBmjr3VIwGmVFO4BPka8L25XYltlEKtcatsIp/GA==
MIME-Version: 1.0
X-Received: by 10.25.22.231 with SMTP id 100mr12255009lfw.153.1454961407614; Mon, 08 Feb 2016 11:56:47 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.49.80 with HTTP; Mon, 8 Feb 2016 11:56:47 -0800 (PST)
In-Reply-To: <41CEFD2751A79CA0424C9D3F@JcK-HP8200.jck.com>
References: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney> <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> <41CEFD2751A79CA0424C9D3F@JcK-HP8200.jck.com>
Date: Mon, 08 Feb 2016 14:56:47 -0500
X-Google-Sender-Auth: 87u2sKOLypbGurb4TvpdjrMsw1U
Message-ID: <CAMm+Lwi2j5BjqGzJ=wizgbVTa0UvB+wykQQSboN0ffirbZdtcQ@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
To: John C Klensin <john-ietf@jck.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/3tJKiZ3OPPhWahnAOzSG5R4oAJk>
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>, webfinger@ietf.org
Subject: Re: [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 19:56:51 -0000

On Mon, Feb 8, 2016 at 2:26 PM, John C Klensin <john-ietf@jck.com> wrote:
> Cyrus,
>
> Thanks for stepping in on this.  A few comments and
> clarifications below...
>
> --On Monday, February 08, 2016 09:54 -0500 Cyrus Daboo
> <cyrus@daboo.name> wrote:

>> For email, calendaring and contacts we do currently have a
>> light weight SRV-based account provisioning solution (RFC6186,
>> RFC6764), which works on a per service basis (i.e., one set of
>> requests for each account type). The calendaring/contacts
>> piece of that has been deployed and used by a number of
>> providers and clients. Unfortunately, the email piece has not
>> - a number of major ISP do publish _imaps etc SRV records, but
>> very few, if any, clients make use of that.
>
> And, as Paul and others have pointed out, SRV-based approaches
> are not particularly well-suited for environments in which the
> configuration information itself may raise privacy issues or in
> which per-user or per-device, rather than per-domain,
> configurations may be needed.  SRV approaches might, however, be
> used to bootstrap the right configuration tools even if they are
> not those tools.

We keep going round in circles in these arguments. We really need some
authoritative source for the Internet architecture.

I agree with John's conclusion but with an older argument. Namely that
people have tried to use DNS for account type information since
RFC1035 was published and none have been successful.

In my view, the DNS is the Infrastructure that maps DNS names onto
current descriptions of services. So extending the use of the DNS for
DANE like purposes with respect to TLS is certainly within scope of
the DNS. Attempting to use the DNS for account based information has
consistently failed.

John's raising of the privacy argument seems to me to be the capstone
of this argument because all of the reasons people have given me for
not making information in LDAP or X.500 directories publicly
accessible are essentially privacy arguments. The concern that head
hunters would use the company directory to cold call people is a form
of privacy argument.

The reason I thought I would flag this is that if we are going to
build such an infrastructure, we should probably start from the idea
that privacy is a paramount concern and plan accordingly.

I do have some code that might be relevant to this problem in the
Mathematical Mesh but it is not a problem that I have considered
except in the abstract so far.


It seems to me that any mechanism that would allow contact information
to be shared would have to leverage two separate principals

1) Social media style 'friend' links
2) Progressive disclosure (aka kimono protocol).

My email information is online but not my telephone number. I really,
really want to get rid of the telephone number ASAP because I am
getting half a dozen spam calls a day now. Even with nomorobo in
place, each spam call still causes one ring and that is starting to be
a hassle.

So if we are looking to support features like calendaring, instant
messaging, VOIP, etc. We really need to have some sort of concept of a
hierarchy of introductions. Something like:

1) Can send me a contact request
2) Can send me an ordinary length text email
3) Can send me large emails and emails with potentially dangerous attachments.
4) Can request voice / video / chat
5) Can put items onto my calendar
6) Can interrupt my work with notifications

The last of course is something that I am going to probably expect to
be paid for.

As I keep saying, there is no problem in providing a cryptographic
infrastructure that supports all these needs in end-to-end security
and in multilayer security models. Give us a clear description of the
requirements, and the crypto is not too hard. The hard part is being
clear about the requirements.


>> 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.
>
> Agreed for either device management or potentially per-user
> application management, but I'm also suggesting that part of
> such an effort should be to examine the many approaches we have
> adopted or tried to adopt to this general class of problems and
> see what we can learn from them, at least to the extent of
> avoiding repeating those mistakes.

+1

> Of course, if there are a collection of almost-good-enough
> proprietary solutions out there, the two other questions that
> should be asked are (i) whether, and how, the IETF can actually
> add value to the situation and (ii) whether those vendors would
> shift to a standardized, interoperable, mechanism rather than
> continuing to push their proprietary ones with whatever
> advantages keeping them proprietary bring.

I think there is a very clear area where IETF can add value, we can
provide a mechanism that puts the user in control rather than being
designed to bind them to one proprietary service provider.

In theory I can use proprietary mechanisms to transfer my email
settings from one device to another. In practice these only work for
the limited set of devices a vendor supports and these in turn tend to
be allowing me to move to the hardware/software of the provider.

There is also a real problem with platform providers who

1) Force me to perform regular software updates
2) Think nothing of trashing my personal settings during an update.

Right now I have an iPhone whining because it hasn't been connected to
the iCloud account I don't use and don't want. I have a Windows
desktop that shuts itself off after 10 minutes despite my repeated
disabling of the power saver mode because one of its functions is as a
server. I also have a large collection of bookmarks that I collected
using the Google Toolbar that I can't properly access from Google
Chrome without the use of a third party plug in that almost certainly
will add malware in a future revision.