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

Phillip Hallam-Baker <ietf@hallambaker.com> Mon, 08 February 2016 20:09 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 286561B3299 for <apps-discuss@ietfa.amsl.com>; Mon, 8 Feb 2016 12:09:57 -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 fuNe4nCFheB8 for <apps-discuss@ietfa.amsl.com>; Mon, 8 Feb 2016 12:09:55 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 7C1B61B3296 for <apps-discuss@ietf.org>; Mon, 8 Feb 2016 12:09:55 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id l143so102839059lfe.2 for <apps-discuss@ietf.org>; Mon, 08 Feb 2016 12:09:55 -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=kCfDQ6jwjrsh9pEVnPsNFr6x2i/NwF0RPQ6AgT8fl78=; b=VQByMcApndOAcvEbYgHNcUiiH1QbsATGPR2ObYPHMWy0u/gTr4846MS2OGTsAcZDQk scEKFcRCVoZ5xGVDbTgspNIIykPR17JWQiovCIZPBqbRwCk32PRu8aH9K3lIdrf4Ic0N ja/7T1YTbvpO45FvgQBLktuZ1OocQV0EXQuXYF1MTO214RuF3d6dWa8xcCik5DDT85bf qJQ5oyCPPg+iA2gb3yd+m77viNqgIUmuu7JLr5qaBZT/GtbE8XO3wFQTMtW1uW8ts9fS lX4+4S2Nd5rscntVf/cVXj1umLqaG0ArYNHCu6/StfOcFVpeHvUz8XGSl0pZ/9YwugB5 fROQ==
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=kCfDQ6jwjrsh9pEVnPsNFr6x2i/NwF0RPQ6AgT8fl78=; b=I8W+PSAF3+h+Z9uvRr5mA+SKELlkOF1L0emayQi3tDX59jaEI3XcGesHy2BCvurdYV 9iMuxYugvWL+DNc1UZBM7pKhhwAyMF5FkVClG3zwWtdmctg2gFQgeczAAX8YcEKcwUZi rvnnzRIJky7H608WCWI02edGmgRaj4ri1kQ8zv1uxYdY9uumxe8c10du5/5V2C6QCZJi YADv5WjsGGkSmlo3WxG5jYkLNqm2Oa87s4exzoo/AUxlzlh5zhymZqTIjzSmYjL3BC7k 5uKk5mPU8HyFhAzUHEsOEYvfdntF7YF5qIYWp4BnNXnArAl9dIlNUN8JJoxTFtuwkNde J2+Q==
X-Gm-Message-State: AG10YOSSTWkHPxTpShVlEiFaewqN4G1qEG/90zvh64am3V6OcbY4U2UQkoHj9D7D+RMp/W92N0MfyvkkL9GCMw==
MIME-Version: 1.0
X-Received: by 10.25.213.196 with SMTP id m187mr7504647lfg.67.1454962193606; Mon, 08 Feb 2016 12:09:53 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.49.80 with HTTP; Mon, 8 Feb 2016 12:09:53 -0800 (PST)
In-Reply-To: <BA5E6D0AE5A63D2306457B2B@JcK-HP8200.jck.com>
References: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney> <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> <8D50E1C3-46FB-4341-B06A-86902B984AEC@standardstrack.com> <BA5E6D0AE5A63D2306457B2B@JcK-HP8200.jck.com>
Date: Mon, 8 Feb 2016 15:09:53 -0500
X-Google-Sender-Auth: Lb9DBzQwoRdkP4mHRq8qAWTI1l0
Message-ID: <CAMm+Lwi=TsnoWMpp4xoW9gvKUqBo9nk+3t0t5YyXkJ6na=+JHw@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/HeKng82bLSAhYtpHYTw9vklYMSg>
Cc: General discussion of application-layer protocols <apps-discuss@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 20:09:57 -0000

On Mon, Feb 8, 2016 at 2:49 PM, John C Klensin <john-ietf@jck.com> wrote:
>
>
> --On Monday, February 08, 2016 10:43 -0500 Eric Burger
> <eburger@standardstrack.com> wrote:
>
>> Perhaps an application-layer DHCP?
>
> Obvious, but another example of why I think we need to look back
> and do some examination.  Something built on a DHCP-like model
> (or, I suspect, on the sort of device identification model
> Claudio mentioned) probably means exposing the device and/or its
> location in all sorts of ways.  That is precisely what assorted
> privacy efforts are trying to avoid.  But Dave suggests (I think
> probably correctly) that one of the fatal flaws with ACAP is
> that it requires a username and hostname.

I may have a solution.


There is another problem I see with ACAP, like the typical Internet
application of its day, it starts with a protocol description and then
it tries to add security.

The Mathematical Mesh is an infrastructure I have designed, build and
demonstrated:

https://www.youtube.com/watch?v=6vM6vxtQzGg
http://www.prismproof.org/

[Yes, there are Internet drafts and the source is MIT license]


The approach in the Mesh is the reverse of the ACAP approach. It was
originally designed as a mechasnism to allow me to easily move public
and private key material around to allow a single user to control
multiple devices connected to a 'profile'. It was designed to support
S/MIME, OpenPGP, SSH, TLS and the like.

It was only after I was writing code to store S/MIME keys in the Mesh
that I suddenly realized that I could just as easily store all the
email configuration data in the Mesh.


The Mesh itself is configured as an untrusted service. In the
demonstration, the server for the Mesh is actually located inside the
dalek you can see in the background. The point being that if you use
strong end-to-end security, you don't need to worry about where your
endpoints lie.

Now one major caveat here is that privacy is a much harder problem
than email encryption and not the problem I set out to solve. At the
moment the Mesh protocols deliberately leave information accessible
that I would like to obfusticate later on because trying to debug a
system in which every identifier is anonymized is probably going to be
a #@($%*#@$(%!!!


> That has other
> problems, but can also lead to a different set of privacy issues
> (including the potential for linking various credentials and
> device information).  One can work around those issues using
> HTTPS with verifiable client certs, but that just changes the
> problem in other ways.  Or one can move to a layered solution,
> hoping that opportunistic encryption based on traditionally
> largely-unverified server credentials will adequately hide the
> private stuff.
>
> Better be sure we know what problem we are trying to solve.

+1

If someone can give me a clear description of 'the' problem, solving
it is easy. What I am trying to do right now is to provide a solution
to the problem we claimed to have solved in 1998/1999 but hadn't.