[Cryptography] Implementations, attacks on DHTs, Mix Nets?

[Phillip Hallam-Baker]

On Tue, Aug 27, 2013 at 10:18 PM, Perry E. Metzger <perry at piermont.com>wrote:

> On Tue, 27 Aug 2013 19:57:30 -0600 Peter Saint-Andre
> <stpeter at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130827/e1199538/attachment.html>