[Cryptography] Dark Mail Alliance specs?

[Phillip Hallam-Baker]

On Sat, Nov 23, 2013 at 6:44 AM, ianG <iang at iang.org> wrote:

> 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 last thing we need now is a second VHS vs Betamax standards war on
secure mail formats.

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.
>

Only the message formats are baked in. The trust model does not need to be
managed in the MUA

I could care less what the format of the messages is. The S/MIME folk have
done a very good job of working out how to get their messages through the
SMTP infrastructure. Why duplicate that.

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


No user interface is needed to receive encrypted S/MIME messages. All that
is required is that the MUA is configured so it can find the decryption
key. That does not need to be done by the MUA, another program can
configure that. Alternatively a one time effort to get the cert and key
into the MUA.

No user interface is needed to send encrypted messages. That can be done by
redirecting outbound mail through a proxy.

To force encryption of an outbound mail, put a ? in front of the mail
address. Let the proxy work out how to send it encrypted.



> 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.
>

http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00

I don't have quite that model. But I do have the idea of combining peer
endorsements and CA endorsements. So the idea is that if I get my key
endorsed by a CA, that endorsement is fixed in tie and has a certain work
factor associated with it. If I get my key endorsed by a peer, that also
has a work factor.

The problem with the peer only model is that it is easy to generate a web
of a million keys all purportedly endorsing each other. The trust needs to
be grounded. Sprinkling in some CA endorsements into a Web grounds the Web.

So in the CA only model the work factor for a distant key is $100 (say)
That is the cost of forging the documents.

In the Web of trust only model, the work factor for the same key would be
$0 because the pat is a friend of a friend of a friend ^n.

In the Web of trust plus 100 CA endorsements model, the cost is $10,000/p
where p is some factor to represent fading due to the distance from the
endorsements. I think p can be kept to a low number.


I think it is viable to establish a Web of trust with some millions of CA
endorsements in it. Which brings the work factor into the hundreds of
millions plus a high risk of being caught.


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.
>

Actually I am not that bothered about who the CAs are as the CA
endorsements would be fixed in time. The attacker does not have a TARDIS to
go back in time and forge a key.

We can build a timestamp notary that does not need to be trustworthy.

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!
>

Then I lose the chance to use that deployed code.

Plus I have an ASN.1 compiler and a JSON compiler that can target the
language(s) of my choice.



> 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.


I would rather stick to JSON and add in a length delimited binary chunk
type.

-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131123/55dcd20d/attachment.html>