Re: [Endymail] spam versus cleartext

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

On Sun, Sep 7, 2014 at 11:09 PM, Viktor Dukhovni <[e-mail]> wrote:
> On Sun, Sep 07, 2014 at 07:06:54PM -0400, John R Levine wrote:
>
>> Take current implementations of S/MIME and adjust them to allow
>> self-signed certificates in addition to (or instead of) ones signed by
>> a list of CAs configured into the MUA.
>
> Apple's desktop Mail.app allows one (via Keychain) to bind a
> particular (self-signed or not) key to a particular sender.  With
> Outlook the only choice is to trust the issuing CA for all addresses.
>
> As for what the IETF can do, maybe address sign-then-encrypt vs.
> encrypt-then-sign in S/MIME unless I missed the memo and this is
> no longer an issue.
>
> The SMIMEA draft is not yet published, I don't recall seeing a
> mechanism there to explicitly publish domain (gateway) keys, in
> addition to or instead of keys for each user.  Perhaps wildcard
> DNS entries can simulate gateway keys.

http://tools.ietf.org/html/draft-hoffman-dane-smime-01


> When SMIMEA records supply only the hash of a trust anchor, or of
> a user certificate, rather than the key, then the relevant public
> keys would have to be conveyed in band.  For example via a reply
> from the user as suggested by Phillip Hallam-Baker.  Thus SMIMEA
> is compatible with various more detailed models of key distribution.

My Omnibroker architecture could pull key information from the DNS.
But I don't see that as a very useful approach for anything finer than
domain level granularity.

The problem is that DNS is a host and service management
infrastructure and email accounts are a user infrastructure. Most
enterprises don't want to mix the two and with good reason. The EU
'privacy' issues are remarkably similar to user concerns about spam.


If you don't want or need finer granularity than the domain, then
putting the records in the DNS is a fine approach - see DKIM. But for
the same reason that the DANE folk ignored DKIM and did their own
thing, I can't see DANE as a very useful starting point. If we were
going to go anywhere then surely going back to DKIM for another email
infrastructure would make more sense.

There is also a difference between use of keys for signature and use
of keys for encryption. With signature verification you already start
from a signed document and that can carry the key. With encryption you
start from the address of the person you want to contact and have to
assemble all the rest of the info somehow.



> SMIMEA might not directly expose the actual public keys of individual
> users or even their hashes, rather it could simply publish a fixed
> certification authority that issues X.509 email certificates to
> the users of a domain.  This can make the initial contact leaf of
> faith more secure.

That is certainly one viable approach. And it is probably a good one
for some applications. But it only really works for the existing
enterprise use case of S/MIME.


If we have [e-mail] then she is a google employee and if I am
talking to her on Google company business then it makes all good sense
to use the Google CA. One of the weaknesses of the PGP model was that
the design ignored the fact that in many circumstances we are in
hierarchical organization structures that the CA model matches very
well.


If we have [e-mail], which could be the same Alice as before
but in her personal capacity then it might make really good sense for
Google to run up a CA for gmail (or contract out to a CA) and issue a
certificate for her validated key. But the certificate issued is only
authenticating [e-mail], it isn't authenticating Alice.

The distinction here is critical if Alice changes email providers or
wants to use her certificate to exchange mail with her bank or a whole
host of similar activities.

[If is also quite possible that gmail.com has separate non-endy keys
which can be used for message level security.]


> So mostly what's missing is new MUA code to support new key management
> models.  Implementations may unearth the need for new headers or
> other relevant standards that enable the new feature set, but my
> guess is that for now what is missing is new code more than new
> standards.  Perhaps this list will produce something unexpected
> that will lead the way to new implementations, but my guess is
> that it will be other way around.

No, what is missing is new Web Service code to implement the prototype
of those systems.

Changing MUAs is hard. It is hard for developers and hard for users.
Which is why I have architected my testbed so that it has an open
source proxy for outbound mail which applies message encryption under
the direction of a trusted Web service.

People use a large number of mail clients - Outlook, Windows Live
Mail, Apple Mail, iOS Mail, Thunderbird, MUTT etc. etc. The only way
to work out if a trust infrastructure is viable is to try it out on a
large scale. Do you really want to have to update seven mail clients
each time we try a test?

Splitting out the trust decisions into a Web Service mean that you can
develop your idea of a trust infrastructure and I can develop mine and
we can make both available to people who use the same code.

I would very much prefer the code that is currently in the proxy to be
in the MUA but right now I want to decouple MUA development and trust
architecture development as far as we can. We can always migrate
functions into the MUA once we understand what they should be.


What I would like to get fixed in MUAs right now is the part that is
handled abysmally on every client I have tried so far: Key management.