STEED - Usable end-to-end encryption

[Micah Anderson]

Hello,

Thanks for working on the STEED concept, I do think that ubiquitous,
easy-to-use encryption is needed and I hope that this moves us closer to
that goal.

I have not fully digested the paper yet, but one thing I wanted to bring
up:

"Marcus Brinkmann" <marcus.brinkmann at ruhr-uni-bochum.de> writes:
> P2P systems are tricky to get right, and have their own tradeoffs.  Also,
> while acceptance for our proposal among service providers will be tough to
> get, I'd expect that getting acceptance for a P2P based system would be even
> harder.  A lot of things have to fall into place to make a P2P network a
> viable alternative, and not all of them are technical.

In the paper, section "III. Opportunistic Encryption" you propose
storing and retreiving certificates be DNS because "... The proposal
automatically benefits from security improvements to DNS. In particular,
DNSSEC disables man-in-the-middle attacks."

It has been shown, many times, how DNSSEC does *not* disable MiTM
attacks. All you are doing by including certificates in DNSSEC is
transferring your trust into a centralized, largely unaccountable, group
of organizations. Haven't we learned from the Certificate Authority
system's problems? The TLD .com is administered by VeriSign, they are
NOT a company that I trust to refrain from doing nefarious things, and
why should I?

The Garfinkel citation seems to include two properties that go against
opportunistic encryption, according to your proposal. One is encrypting
the headers of email; the second is to include the certificates in the
email. The rationale for rejecting the certificates being included is
that you lose secure initial contact, which I cannot disagree
with. However, if we weren't completely throwing out the decentralized,
strong cryptographic models that OpenPGP's PKI has (which guards us
against centralized failure modes) to adopt a completely centralized
model that DNSSEC brings us, then we could consider a hybrid model of
trust where individual users have control over who to trust to verify
authenticity, but also have the flexibility to delegate trust where they
desire.

I dont know the solution here, but replacing the OpenPGP PKI with DNSSEC
seems suboptimal. you could instead ship the certificate AND use DNSEC,
and allow for other mechanism, notaries etc. This provides secondary, or
tertiary network perspectives from which to correlate and verify
certificates, rather than handing it all over to a centralized
authority. Its easy to MiTM DNSEC if you are a government, but if you
were *also* shipping the certificate in the email, then the burden of
compromise has been increased, you now also have to also own the
transports between the two MTAs, which may be difficult if they are
doing TLS, but its a lot better than just handing things over to
Verisign. If I had the flexibility to delegate some level of notarized
trust to an organization that I trust to certify certain things, then
I'd be in a much more comfortable position than is offered by STEED's
proposal.

micah