[148225] in cryptography@c2.net mail archive
Re: [Cryptography] Dark Mail Alliance specs?
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Sat Nov 23 19:08:05 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <52909514.20605@iang.org>
Date: Sat, 23 Nov 2013 16:24:08 -0500
From: Phillip Hallam-Baker <hallam@gmail.com>
To: ianG <iang@iang.org>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============4266816480914197883==
Content-Type: multipart/alternative; boundary=089e011827ae4b930404ebdec009
--089e011827ae4b930404ebdec009
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Nov 23, 2013 at 6:44 AM, ianG <iang@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/
--089e011827ae4b930404ebdec009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Nov 23, 2013 at 6:44 AM, ianG <span dir=3D"ltr"><<a href=
=3D"mailto:iang@iang.org" target=3D"_blank">iang@iang.org</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex">
<div class=3D"im">On 22/11/13 19:30 PM, Phillip Hallam-Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
Does anyone know what the Dark Mail Alliance specs might look like?<br>
<br>
I have been trying to contact the principals with no success.<br>
</blockquote>
<br>
<br></div>
Shrink, Steal, Compete. =A0Don't try and form a committee ;-)</blockquo=
te><div><br></div><div>The last thing we need now is a second VHS vs Betama=
x standards war on secure mail formats.</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">But, the format is lo=
cked into the MUA. =A0So it has no bearing to anyone, as we can't chang=
e the design locked into N*MUAs.</span></div></blockquote><div><br></div><d=
iv>
Only the message formats are baked in. The trust model does not need to be =
managed in the MUA</div><div><br></div><div>I could care less what the form=
at 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 duplica=
te that.=A0</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
I'm obviously missing something here -- what can be done with S/MIME th=
at unlocks the formats within the MUAs?</blockquote><div><br></div><div>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. T=
hat 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.</di=
v>
<div><br></div><div>No user interface is needed to send encrypted messages.=
That can be done by redirecting outbound mail through a proxy.=A0</div><di=
v><br></div><div>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.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div class=3D"im"><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left=
:1ex">
I see a need for at least three distinct trust exchange models:<br>
<br>
1) Direct out of band trust.<br>
2) Peer-to-Peer Endorsement<br>
3) CA managed certificates<br>
</blockquote>
<br></div>
3a. root-list supplied CAs<br>
3b. peer- or user-endorsed CAs<br>
<br>
Practically speaking, people will look for endorsements over CAs. =A0At the=
moment, there is no choice here, you get imposed by the ubur-CA called the=
mail vendor, and it is hidden.<br></blockquote><div><br></div><div><a href=
=3D"http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00">http:=
//tools.ietf.org/html/draft-hallambaker-prismproof-trust-00</a><br>
</div><div><br></div><div>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 an=
d has a certain work factor associated with it. If I get my key endorsed by=
a peer, that also has a work factor.</div>
<div><br></div><div>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 W=
eb grounds the Web.</div>
<div><br></div><div>So in the CA only model the work factor for a distant k=
ey is $100 (say) That is the cost of forging the documents.</div><div><br><=
/div><div>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.</div>
<div><br></div><div>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 di=
stance from the endorsements. I think p can be kept to a low number.</div>
<div><br></div><div><br></div><div>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.</di=
v>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">
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. =A0E.g., just =
go with Iang's list or EFF's list or the Politburo's list. Obvi=
ously, 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.<br>
<br>
One list does not work.<br></blockquote><div><br></div><div>Actually I am n=
ot that bothered about who the CAs are as the CA endorsements would be fixe=
d in time. The attacker does not have a TARDIS to go back in time and forge=
a key.=A0</div>
<div><br></div><div>We can build a timestamp notary that does not need to b=
e trustworthy.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">I wouldn't sugges=
t using that old stuff. =A0Pick something well portable/ported and entirely=
distinct with a trivially small footprint, so that the code can be deliver=
ed in the app without any needs for any external library support.</span><br=
>
</div>
<br>
You've got a chance to dump the legacy, take it!<br></blockquote><div><=
br></div><div>Then I lose the chance to use that deployed code.</div><div><=
br></div><div>Plus I have an ASN.1 compiler and a JSON compiler that can ta=
rget the language(s) of my choice.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex">
Protocol Buffers from google is the closest thing I've seen of late, bu=
t it might already be too complex and require external libraries and develo=
pers to learn YetAnotherFormatLanguage. </blockquote><div><br></div><div>
I would rather stick to JSON and add in a length delimited binary chunk typ=
e.</div></div><div><br></div>-- <br>Website: <a href=3D"http://hallambaker.=
com/">http://hallambaker.com/</a><br>
</div></div>
--089e011827ae4b930404ebdec009--
--===============4266816480914197883==
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
--===============4266816480914197883==--
