[Cryptography] Dark Mail Alliance specs?

[ianG]

On 22/11/13 19:30 PM, Phillip Hallam-Baker wrote:
> Does anyone know what the Dark Mail Alliance specs might look like?
>
> I have been trying to contact the principals with no success.


Shrink, Steal, Compete.  Don't try and form a committee ;-)


> The scheme I am working on allows people to exchange secure email using
> 99% of the already deployed MUAs without any updates, plug ins or
> patches. The basic idea is to decouple the problem of trust management
> from the question of message formats.
>
> As far as message formats go, S/MIME has completely won the battle.
> Virtually every mail client that supports secure mail supports S/MIME
> and virtually everyone who uses an MUA rather than WebMail uses one that
> has S/MIME built in.


But, the format is locked into the MUA.  So it has no bearing to anyone, 
as we can't change the design locked into N*MUAs.

I'm obviously missing something here -- what can be done with S/MIME 
that unlocks the formats within the MUAs?


> On the trust side I think that people have been thinking about the
> problem in a very unhelpful way. PGP's Web of trust is better for some
> groups of people and S/MIME's CA managed trust is better for other
> groups of people.
>
> If I am sending mail on Comodo business people are going to be asking
> 'is this mail from Comodo' at least as often as 'is this mail from PHB'.


Yes.  This gets into the fallacy of signing -- what is the statement 
being signed?  For PGP it is "I met this person, maybe."  For the CAs, 
it is "the person had some identity docs, maybe."  These are rather 
vacuous statements, of about the same value as the TOFU statement "this 
key is the same nym as it was last time."

I'm not sure what the answer is, but if one supports all statements then 
competition might allow a better economics to emerge.

> Why did we get the idea that there was no room for both approaches? Why
> not have a scheme that allows people to make use of any trust model they
> find works for them?
>
>
> I see a need for at least three distinct trust exchange models:
>
> 1) Direct out of band trust.
> 2) Peer-to-Peer Endorsement
> 3) CA managed certificates

3a. root-list supplied CAs
3b. peer- or user-endorsed CAs

Practically speaking, people will look for endorsements over CAs.  At 
the moment, there is no choice here, you get imposed by the ubur-CA 
called the mail vendor, and it is hidden.

But in terms of the marketplace and the way users think, what they want 
is some sort of more localised trust list that they can choose.  E.g., 
just go with Iang's list or EFF's list or the Politburo's list. 
Obviously, people in Iran aren't that happy with the USA-dominated list 
of CAs, and people in the Pentagon aren't that keen on Mozilla's list 
including an Iranian CA.

One list does not work.

This mechanism can then be seen as separating the list from the 
application, or as you might put it:  decouple the problem of trust 
management from the application.

In this way, we would get the compromise of both worlds.  Mozilla's list 
might be chosen by many, but there are also a lot who won't want the 
worldwide grabbag of CAs which adds risks to those who care.


> Plus (0) Self endorsement of short term keys from longer term keys.
>
>
> The way I support direct out of band trust is through a 'Strong email
> address' which is essentially just a fingerprint prepended to a
> KeyIdentifier.


In practice, this is very important.  To make this product work, you are 
going to have to succeed without the support of the vendors, which means 
you'll have to develop support heavily towards 1) and 2).

The process will need to be slick;  Skype is the standard.


> 1) If the email address contains a ?, the mail will not be sent unless
> it can be sent under a security policy acceptable to the sender. This
> typically means end to end encryption using S/MIME or PGP.


I would leave any blocking until last.  Yes, we as security folk are 
horrified when an email slips out unprotected.  But, they the people are 
horrified when the email doesn't go, regardless of anything else.

Communication is the primary objective of the people, security is a 
secondary one.  K6 says they turn the product off and then you lose.

(OK, I suspect you're probably thinking the same thoughts anyway.)


...

> As far as wireline formats go my approach is:
>
> 1) All the crypto in ASN.1 (yuk!)
> 2) Everything else in JSON or simple extensions thereof (e.g. JSON-ABC)
> 3) All Web services over HTTPS with client authentication at the HTTP layer.
>
> A bare bones scheme does not require any web service at all. The public
> key and policy files can be fetched from a HTTP URL places at a
> .well-known location.


I wouldn't suggest using that old stuff.  Pick something well 
portable/ported and entirely distinct with a trivially small footprint, 
so that the code can be delivered in the app without any needs for any 
external library support.

You've got a chance to dump the legacy, take it!

Protocol Buffers from google is the closest thing I've seen of late, but 
it might already be too complex and require external libraries and 
developers to learn YetAnotherFormatLanguage.  All that is needed for 
just about everything is an integer and a byte array, everything else is 
composable in objects over streams.  Once that is done, you can do 
precise checking in each object over basic primitives, so semantics and 
syntax are covered in one.

Death is to involve another language.  At this point, weaknesses start 
to erupt at the crack between the languages, and security fails.  Costs 
mount as developers need to be adept in more tools than they can 
comfortably master, and still have time to write app code.

Oh, yes, critical assumption:  it's all OO these days, and the non-OO 
people should not be catered to.




Another extremely important problem is metadata or as we now know it, 
fodder for mass surveillance.  Unless there is something in there to 
handle that issue, I suspect the result will be a lot of work for 
limited utility.

Even a single hop would be enough to break the metadata chain...  It 
doesn't need to be sophisticated, to begin with.



iang