[146429] in cryptography@c2.net mail archive
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Wed Aug 28 00:07:25 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130827221818.56bd2467@jabberwock.cb.piermont.com>
Date: Tue, 27 Aug 2013 22:34:05 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: Cryptography List <cryptography@metzdowd.com>,
Jonathan Thornburg <jthorn@astro.indiana.edu>,
Peter Saint-Andre <stpeter@stpeter.im>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8565042194226505280==
Content-Type: multipart/alternative; boundary=001a11c37ababd997e04e4f8d21a
--001a11c37ababd997e04e4f8d21a
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Aug 27, 2013 at 10:18 PM, Perry E. Metzger <perry@piermont.com>wrote:
> On Tue, 27 Aug 2013 19:57:30 -0600 Peter Saint-Andre
> <stpeter@stpeter.im> wrote:
> > On 8/27/13 7:47 PM, Jonathan Thornburg wrote:
> > > On Tue, 27 Aug 2013, Perry E. Metzger wrote:
> > >> Say that you want to distribute a database table consisting of
> > >> human readable IDs, cryptographic keys and network endpoints for
> > >> some reason. Say you want it to scale to hundreds of millions of
> > >> users.
> > >
> > > This sounds remarkably like a description of DNSSEC.
> > >
> > > Assuming it were widely deployed, would
> > > DNSSEC-for-key-distribution be a reasonable way to store
> > > email_address --> public_key
> > > mappings?
> >
> > You mean something like this (email address --> OTR key)?
> >
> > https://datatracker.ietf.org/doc/draft-wouters-dane-otrfp/
>
> My problem with the use of DNSSEC for such things is the barrier to
> entry. It requires that a systems administrator for the domain your
> email address is in cooperate with you. This has even slowed DNSSEC
> deployment itself.
>
How about the fact that the US govt de facto controls the organization
controlling the root key and it is a single rooted hierarchy of trust?
But in general, the DNS is an infrastructure for making assertions about
hosts and services. It is not a good place for assertions about users or
accounts. So it is a good place to dump DANE records for your STARTTLS
certs but not for S/MIME certs.
> It is, of course, clearly the "correct" way to do such things, but
> trying to do things architecturally correctly sometimes results in
> solutions that don't deploy.
>
> I prefer solutions that require little or no buy in from anyone other
> than yourself. One reason SSH deployed so quickly was it needed no
> infrastructure -- if you controlled a single server, you could log in
> to it with SSH and no one needed to give you permission.
>
> This is a guiding principle in the architectures I'm now considering.
I very much agree that deployment is all.
One thing I would like to do is to separate the email client from the
crypto decision making even if this is just a temporary measure for testbed
purposes. I don't want to hack plugs into a dozen email clients for a dozen
experiments and have to re-hack them for every architectural tweak.
--
Website: http://hallambaker.com/
--001a11c37ababd997e04e4f8d21a
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 Tue, Aug 27, 2013 at 10:18 PM, Perry E. Metzger <span dir=3D"ltr=
"><<a href=3D"mailto:perry@piermont.com" target=3D"_blank">perry@piermon=
t.com</a>></span> 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">On Tue, 27 Aug 2013 19:57:30 -0600 Peter Saint-Andre<br>
<<a href=3D"mailto:stpeter@stpeter.im">stpeter@stpeter.im</a>> wrote:=
<br>
<div class=3D"im">> On 8/27/13 7:47 PM, Jonathan Thornburg wrote:<br>
> > On Tue, 27 Aug 2013, Perry E. Metzger wrote:<br>
> >> Say that you want to distribute a database table consisting o=
f<br>
> >> human readable IDs, cryptographic keys and network endpoints =
for<br>
> >> some reason. Say you want it to scale to hundreds of millions=
of<br>
> >> users.<br>
> ><br>
> > This sounds remarkably like a description of DNSSEC.<br>
> ><br>
> > Assuming it were widely deployed, would<br>
> > DNSSEC-for-key-distribution be a reasonable way to store<br>
> > =A0 email_address --> public_key<br>
> > mappings?<br>
><br>
</div>> You mean something like this (email address --> OTR key)?<br>
><br>
> <a href=3D"https://datatracker.ietf.org/doc/draft-wouters-dane-otrfp/"=
target=3D"_blank">https://datatracker.ietf.org/doc/draft-wouters-dane-otrf=
p/</a><br>
<br>
My problem with the use of DNSSEC for such things is the barrier to<br>
entry. It requires that a systems administrator for the domain your<br>
email address is in cooperate with you. This has even slowed DNSSEC<br>
deployment itself.<br></blockquote><div><br></div><div>How about the fact t=
hat the US govt de facto controls the organization controlling the root key=
and it is a single rooted hierarchy of trust?<br></div><div><br></div>
<div>But in general, the DNS is an infrastructure for making assertions abo=
ut hosts and services. It is not a good place for assertions about users or=
accounts. So it is a good place to dump DANE records for your STARTTLS cer=
ts but not for S/MIME certs.</div>
<div>=A0</div><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">
It is, of course, clearly the "correct" way to do such things, bu=
t<br>
trying to do things architecturally correctly sometimes results in<br>
solutions that don't deploy.<br>
<br>
I prefer solutions that require little or no buy in from anyone other<br>
than yourself. One reason SSH deployed so quickly was it needed no<br>
infrastructure -- if you controlled a single server, you could log in<br>
to it with SSH and no one needed to give you permission.<br>
<br>
This is a guiding principle in the architectures I'm now considering.</=
blockquote><div><br></div><div>=A0I very much agree that deployment is all.=
=A0</div></div><div><br></div><div>One thing I would like to do is to separ=
ate the email client from the crypto decision making even if this is just a=
temporary measure for testbed purposes. I don't want to hack plugs int=
o a dozen email clients for a dozen experiments and have to re-hack them fo=
r every architectural tweak.</div>
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
allambaker.com/</a><br>
</div></div>
--001a11c37ababd997e04e4f8d21a--
--===============8565042194226505280==
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
--===============8565042194226505280==--
