[148215] in cryptography@c2.net mail archive
[Cryptography] Dark Mail Alliance specs?
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Fri Nov 22 22:36:40 2013
X-Original-To: cryptography@metzdowd.com
Date: Fri, 22 Nov 2013 11:30:08 -0500
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3027100929229224225==
Content-Type: multipart/alternative; boundary=047d7b3a80a00645c904ebc687cb
--047d7b3a80a00645c904ebc687cb
Content-Type: text/plain; charset=ISO-8859-1
Does anyone know what the Dark Mail Alliance specs might look like?
I have been trying to contact the principals with no success.
Its no secret that I am working on a secure email scheme based on PGP and
S/MIME and have proposed a series of drafts to the IETF. It would be nice
if this time round we could end up with one specification rather than two.
The rest of this message is a heads up for folk who are interested in
working on this problem that there are code projects they might consider.
Given all the crap I have done with government agencies over the past two
decades I don't think people would be well advised to place absolute
reliance on my code even if it is open source. I also don't want to rely on
just one crypto stack.
The good news for folk wanting to do that is that since I work in C#,
anyone else who wants to write an implementation of one or both of the
tools has a free choice of any of the crypto libraries in C or even
Java/python/etc.
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.
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'.
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
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.
To enable backward compatibility with PGP there is a convention that if the
KeyID has a : separator in it then it is a PGP fingerprint in hex. So
people will be able to use the toolset to send mail to PGP users in PGP
format.
The first tool is almost working now and generates a keypair for the user:
Generating Key
Writing to file Alice.keyfile
Key Identifier is ADAEXA-G4UKAN-UADASXA-JQAGBS-XAA
Strong email address is ADAEXA-G4UKAN-UADASXA-JQAGBS-XAA?
alice@hallambaker.com
Right now I only generate one keypair for encryption use only. But the long
term plan is to generate a master keypair that has no predefined expiry
time and then use that to sign temporary keys for signing and encryption.
The second tool is a simple mail proxy which I am working on. The idea is
that you redirect your outbound mail through the proxy. The idea is that
this will perform enhancement of mail as follows:
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.
2) If the email address contains a ? and has a fingerprint, the mail will
only be sent if it can ALSO be encrypted under a policy that has been
signed under a key that is accredited under the specified public key.
3) Otherwise the proxy will attempt to locate a sending policy for the
domain from a policy service. If the receiver has specified a receiving
policy with a preference for end to end encryption, the message is
encrypted opportunistically.
Based on my calculations and simulations, I believe that the design using
only direct out of band trust can scale to an arbitrary number of users but
it only provides reliable trust when there is an opportunity for direct
exchange.
Which is a lot better than where we are now but not where I want to stop.
But that is the fun part of the project where there is room for lots of
ideas and innovation. Right now we have to fix the plumbing.
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.
The next step up requires two very simple Web services to support key
publication to the trust infrastructure(s) and key discovery/validation.
Allowing people to use multiple devices requires another two Web services,
an account establishment/management service and the confirmation service I
proposed earlier.
Once we get beyond that into trust infrastructures it will get a lot more
complicated as what we are doing is essentially research. But I don't think
we will need to be there for 18 months even by a very optimistic adoption
curve.
--
Website: http://hallambaker.com/
--047d7b3a80a00645c904ebc687cb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Does anyone know what the Dark Mail Alliance specs might l=
ook like?<div><br></div><div>I have been trying to contact the principals w=
ith no success.</div><div><br></div><div>Its no secret that I am working on=
a secure email scheme based on PGP and S/MIME and have proposed a series o=
f drafts to the IETF. It would be nice if this time round we could end up w=
ith one specification rather than two.</div>
<div><br></div><div>The rest of this message is a heads up for folk who are=
interested in working on this problem that there are code projects they mi=
ght consider. Given all the crap I have done with government agencies over =
the past two decades I don't think people would be well advised to plac=
e absolute reliance on my code even if it is open source. I also don't =
want to rely on just one crypto stack.</div>
<div><br></div><div>The good news for folk wanting to do that is that since=
I work in C#, anyone else who wants to write an implementation of one or b=
oth of the tools has a free choice of any of the crypto libraries in C or e=
ven Java/python/etc.</div>
<div><br></div><div><br></div><div>The scheme I am working on allows people=
to exchange secure email using 99% of the already deployed MUAs without an=
y updates, plug ins or patches. The basic idea is to decouple the problem o=
f trust management from the question of message formats.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>On the trust side I think that people ha=
ve been thinking about the problem in a very unhelpful way. PGP's Web o=
f trust is better for some groups of people and S/MIME's CA managed tru=
st is better for other groups of people.=A0</div>
<div><br></div><div>If I am sending mail on Comodo business people are goin=
g to be asking 'is this mail from Comodo' at least as often as '=
;is this mail from PHB'.</div><div><br></div><div>Why did we get the id=
ea that there was no room for both approaches? Why not have a scheme that a=
llows people to make use of any trust model they find works for them?</div>
<div><br></div><div><div><br></div><div>I see a need for at least three dis=
tinct trust exchange models:</div><div><br></div><div>1) Direct out of band=
trust.</div><div>2) Peer-to-Peer Endorsement</div><div>3) CA managed certi=
ficates</div>
<div><br></div><div>Plus (0) Self endorsement of short term keys from longe=
r term keys.<br></div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>To enable backward compatibility with PGP there is a co=
nvention that if the KeyID has a : separator in it then it is a PGP fingerp=
rint in hex. So people will be able to use the toolset to send mail to PGP =
users in PGP format.</div>
<div><br></div><div><br></div><div>The first tool is almost working now and=
generates a keypair for the user:</div><div><br></div><div><div>Generating=
Key</div><div>Writing to file Alice.keyfile</div><div>Key Identifier is AD=
AEXA-G4UKAN-UADASXA-JQAGBS-XAA</div>
<div>Strong email address is ADAEXA-G4UKAN-UADASXA-JQAGBS-XAA?<a href=3D"ma=
ilto:alice@hallambaker.com">alice@hallambaker.com</a></div></div><div><br><=
/div><div>Right now I only generate one keypair for encryption use only. Bu=
t the long term plan is to generate a master keypair that has no predefined=
expiry time and then use that to sign temporary keys for signing and encry=
ption.</div>
<div><br></div><div><br></div><div>The second tool is a simple mail proxy w=
hich I am working on. The idea is that you redirect your outbound mail thro=
ugh the proxy. The idea is that this will perform enhancement of mail as fo=
llows:</div>
<div><br></div><div>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 se=
nder. This typically means end to end encryption using S/MIME or PGP.</div>
<div><br></div><div>2) If the email address contains a ? and has a fingerpr=
int, the mail will only be sent if it can ALSO be encrypted under a policy =
that has been signed under a key that is accredited under the specified pub=
lic key.</div>
<div><br></div><div>3) Otherwise the proxy will attempt to locate a sending=
policy for the domain from a policy service. If the receiver has specified=
a receiving policy with a preference for end to end encryption, the messag=
e is encrypted opportunistically.</div>
<div><br></div><div><br></div><div>Based on my calculations and simulations=
, I believe that the design using only direct out of band trust can scale t=
o an arbitrary number of users but it only provides reliable trust when the=
re is an opportunity for direct exchange.=A0</div>
<div><br></div><div>Which is a lot better than where we are now but not whe=
re I want to stop. But that is the fun part of the project where there is r=
oom for lots of ideas and innovation. Right now we have to fix the plumbing=
.</div>
<div><br></div><div><br></div><div>As far as wireline formats go my approac=
h is:</div><div><br></div><div>1) All the crypto in ASN.1 (yuk!)</div><div>=
2) Everything else in JSON or simple extensions thereof (e.g. JSON-ABC)</di=
v>
<div>3) All Web services over HTTPS with client authentication at the HTTP =
layer.</div><div><br></div><div>A bare bones scheme does not require any we=
b service at all. The public key and policy files can be fetched from a HTT=
P URL places at a .well-known location.</div>
<div><br></div><div>The next step up requires two very simple Web services =
to support key publication to the trust infrastructure(s) and key discovery=
/validation.</div><div><br></div><div>Allowing people to use multiple devic=
es requires another two Web services, an account establishment/management s=
ervice and the confirmation service I proposed earlier.</div>
<div><br></div><div>Once we get beyond that into trust infrastructures it w=
ill get a lot more complicated as what we are doing is essentially research=
. But I don't think we will need to be there for 18 months even by a ve=
ry optimistic adoption curve.</div>
<div><br></div><div><br></div><div><br></div>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>
--047d7b3a80a00645c904ebc687cb--
--===============3027100929229224225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============3027100929229224225==--
