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

Phillip Hallam-Baker <ietf@hallambaker.com> Thu, 18 July 2019 16:03 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: webfinger@ietfa.amsl.com
Delivered-To: webfinger@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D5F1207BD; Thu, 18 Jul 2019 09:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.557
X-Spam-Level:
X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 HnkNHxWioSry; Thu, 18 Jul 2019 09:03:05 -0700 (PDT)
Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (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 2A62F1207EE; Thu, 18 Jul 2019 09:03:05 -0700 (PDT)
Received: by mail-ot1-f49.google.com with SMTP id s20so29593025otp.4; Thu, 18 Jul 2019 09:03:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D+ie+Ch58f+IOhc9Uc1evnctbltGjtb3uGI3DcdMryA=; b=ix2lHnLWITVwA+7AuI4MHT+8ngVfDvo9jPa5RtzrmENqPbg+2ce9UV0jKp8mqwQ0eD Zcme2sGmK7NAm0Cid+OpbOO9YIpfKlYXv2m9OgLgjW6BXZCjmJw9O7skXSo1V3qCO0dw rNJ/djPDF2VOX89BnwUdWJcvQCWpzu+0a+nuy675E9isN76UvJh7ufHHGfb1aUWzmrph DEkz+9kD2naReKIxkuxLqKHhUWcnzoCpgdhnnDYPDo9ZbWq2uHDSH7Q8PuSZ9cJ+S9sJ DA++P/8VNip2yJfWaqsgg77Lf1cIFDAt70QnCdICpNnp4I1D/bQG0cl/9M5m5eLDYbox uowA==
X-Gm-Message-State: APjAAAU7NYdKZkNWlgFS0pa2K8wJBEmrAGvPnpjIQw/ARjXDEirDOPem RUoREpBO02Qo9UtqTR/UXEVWkeHM8ZFFAa16uFy4fA==
X-Google-Smtp-Source: APXvYqyatqYUndTR/qEJeZi0UhDnWG3sFs7vnzMt/mOQ4AufS8MvQepq5+58OEC0N0q/KPaQgolYiHLzymqDFsrH90w=
X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr36934709otr.231.1563465784348; Thu, 18 Jul 2019 09:03:04 -0700 (PDT)
MIME-Version: 1.0
References: <eme8317959-26f9-4a9d-b2be-d2f8cb0961f6@sydney> <CAKHUCzw=qo+C6H0Zwd7r3Osn0O5A11nOLEA6=vc18vxZZ_=4Jw@mail.gmail.com> <4BB105E1-0973-4416-8C2A-A729CD869C8A@packetizer.com>
In-Reply-To: <4BB105E1-0973-4416-8C2A-A729CD869C8A@packetizer.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
Date: Thu, 18 Jul 2019 12:02:53 -0400
Message-ID: <CAMm+LwifuP=z5PDzJcwFF=hHBXbSs6_PCz6arTmYGjYoBfpMOw@mail.gmail.com>
To: "Paul E. Jones" <paulej=40packetizer.com@dmarc.ietf.org>
Cc: Dave Cridland <dave@cridland.net>, "art@ietf.org" <art@ietf.org>, "webfinger@ietf.org" <webfinger@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b1d5e2058df6bef9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webfinger/lATzG4Pxm9Zpi59viB2DmiEJyns>
Subject: Re: [webfinger] [art] Auto-configuring Email Clients via WebFinger
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 18 Jul 2019 16:03:07 -0000

Responding to Paul's point about his wife needing a country specific
configuration, I think we need to think about this a bit differently.

This is one example of an application configuration problem and a service
discovery problem. What we need here is a scheme that is capable of
supporting the general case.

It makes no sense for any of the providers to change their existing schemes
unless it is to move to a scheme that is more powerful because it is more
general. Which means that at minimum it is supported by all the MUAs but
ideally means it is supported by multiple applications as well.

I have been thinking about this problem from the other side. I started what
is now the Mathematical Mesh trying to work out how to automatically
configure and maintain S/MIME and OpenPGP. While doing that, I suddenly
realized that I could add in the SMTP configuration as well. So once Alice
has configured her email service on one device, it is configured for them
all. She will get her SUBMIT/IMAP/POP3 settings at the same time that she
gets the S/MIME and OpenPGP keys to work on the device. I showed this to
Dave Clark who asked for SSH as well (which is a real pig to configure as
there is a bootstrap problem and a foul up may require someone to take a
plane trip to a server to fix it).

Being able to replicate the config across devices does not solve the
problem of initial acquisition of course. But the replication mechanism
should certainly use the same data structure (though translated to JSON
probably).


I have not thought about the Enterprise application of the Mesh in detail
yet because I have to get it working for individual users first. But I am
pretty sure that what we want here is single point onboarding (and
terminations).

So Alice joins example.com. She is issued a (new) company laptop and BYOB's
her mobile.

The onboarder checks the boxes for the corporate applications she is
authorized for, email, ssh, etc. and the group encryption services for the
teams she belongs to. The configulator then does all the rest.

All that remains is to connect up Alice and her devices to these
configurations. Which can be done in person via QR code or remotely via a
Base32 fingerprint. It presents a workfactor of at least 2^112 either way.

So from Alice's point of view, when she goes to the badge office to pick up
her badge, she scans a QR code with her phone and that is it - she is all
configured for email, chat, slack, slick, ssh, S/MIME and all the encrypted
data she needs from the cloud. If she is working on some really sensitive
stuff, her line manager or a VP might need to meet her in person to
authorize adding her to certain groups.

Termination should mean no more than unchecking the boxes.


The cryptography I am using was discovered by Torben Pedersen and Matt
Blaze in the mid 1990s. The reason it hasn't been applied was that it was
too hard to use and until Robert Snowden came along, people thought the
administrator of the key service in the cloud could be trusted. So I have
made it really easy to use and administrate even in the case that we have
separation of duties at the administrator level as well.


On Thu, Jul 18, 2019 at 10:12 AM Paul E. Jones <paulej=
40packetizer.com@dmarc.ietf.org>; wrote:

> Dave,
>
> RFC 6186 is the DNS-based one to which I referred below. Unfortunately, it
> doesn't allow setting various configuration options and wouldn't work at
> all for my wife's use case where employees use different mail servers based
> on the country in which they reside.
>
> Paul
>
> ------------------------------
> *From:* Dave Cridland <dave@cridland.net>;
> *Sent:* July 18, 2019 4:40:41 AM EDT
> *To:* "Paul E. Jones" <paulej@packetizer.com>;
> *Cc:* "art@ietf.org"; <art@ietf.org>;, "webfinger@ietf.org"; <
> webfinger@ietf.org>;
> *Subject:* Re: [art] Auto-configuring Email Clients via WebFinger
>
> Obviously I'd prefer ACAP.
>
> But also, please note the existence of RFC 6186. It's not widely deployed,
> but if we were to open this can of worms, and not simply reuse
> Thunderbird's autoconfig XML format (which, if I recall, is also supported
> by various other Open Source MUAs), then I'd be keen to get SRV up and
> running properly.
>
> Dave.
>
> On Mon, 15 Jul 2019 at 20:31, Paul E. Jones <paulej=
> 40packetizer.com@dmarc.ietf.org>; wrote:
>
>> ART folks,
>>
>> Several years ago when I was working on WebFinger, one of the use cases I
>> presented was using WebFinger to facilitate auto-configuring email
>> clients.  It was and still is a problem I deal with today.
>>
>> For my own family, I have to manually configure several different clients
>> on several different platforms for each member of the family.  It's time
>> consuming and really needs to be made simpler.
>>
>> My wife also has to deal with this issue where she works, because her
>> company, while just 100 or so employees, has offices in two different
>> countries and the mail server settings an employee uses depends on his or
>> her geographic location.  To use standard IETF protocols, it means a lot of
>> manual provisioning.
>>
>> I see the same sort of challenges with service providers. If one wants to
>> have his or her own domain, but isn't technically savvy, they're in for a
>> lot of "fun" trying to figure out the various settings. Seriously, no
>> normal person should have to understand what SMTP or IMAP means, and
>> definitely what port numbers or security settings to fill in.
>>
>> While there has been a generic DNS-based method for email provision for a
>> while, it doesn't work for me. It doesn't work for my wife's company,
>> either. It also doesn't define everything one might need to define (e.g.,
>> required security settings or policies).
>>
>> So we put together a very simple example to show how this might be done
>> with WebFinger.  See the draft here:
>> https://tools.ietf.org/html/draft-jones-webfinger-email-autoconfig-00
>>
>> The example in that document should make it clear how we intend this to
>> work, though the detailed procedures and syntax are missing.  We first want
>> to see what interest exists and if this general approach will work for
>> everyone before getting into too much detail.
>>
>> We'd love to have some dialog on this to see how we can address this
>> problem of auto-configuring email clients.
>>
>> Paul
>>
>> _______________________________________________
>> art mailing list
>> art@ietf.org
>> https://www.ietf.org/mailman/listinfo/art
>>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>