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

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Feb 8, 2016 at 2:49 PM, John C Klensin <[e-mail]> wrote:
>
>
> --On Monday, February 08, 2016 10:43 -0500 Eric Burger
> <[e-mail]> 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.