STEED - Usable end-to-end encryption

[Marcus Brinkmann]

On 10/19/2011 08:07 PM, Harakiri wrote:
> Here is some input, you might not like it - but still:

Thanks, we certainly appreciate your feedback!

> I dont see any ground breaking new approaches to the topic - key search via DNS has been in commercial products for over 10 years already - nothing new - heck isnt there even an RFC that describes this?

Right, and we don't claim to have ground breaking new ideas, just a careful
combination of well established and tested ideas.  I consider this to be a
strength, not a weakness.

> Letting the keys automatically be generated by the client is not a new approach either commercial solutions do this too - however - did you think of the keys the user already has? His ID for example - you are sponsored by the german government - the first thing which should have come into your mind is that everybody can use his "Personalausweis" as a Smartcard because it already has a private/public keypair. Other european countries could follow...

Usability is tricky business.  A lot of it seems obvious or trivial, yet over
and over again we fail to create usable software systems due to various
pressures that lead us astray.  We outlined in the paper how usability
barriers can hopefully be overcome consistently (previous efforts have
focussed on individual problems in isolation).  Automatic key generation is as
important as automatic key distribution and the other suggestions that work in
combination for maximum effect.  But automatic key generation alone is not
sufficient, and the paper is about the combination of features rather than
each individual feature in isolation.

As for pre-existing keys, we do not mention nationally issued certificates in
particular, but we do mention smart cards and other reasons to use
pre-existing keys (that we consider to be more relevant and probably than a
desire to use nationally issued certificates in the near future).  A provision
can be made for them, but they can not be mandatory, for technical, usability
and privacy reasons.

> Also - inventing just ANOTHER protocol for email encryption that mail clients should implement? Heck, the only protocol available in all major mail clients right now for out of the box encryption is only smime - for PGP you need plugins - even after so many years there is no out of the box solution for the other major standard - lets not talk about all the compatibility issues with smime in all existing clients. And you just want add another NEW standard which will solve issues? I dont think so.

STEED does not create a new protocol for email encryption but reuses and is
fully compatible to OpenPGP and S/MIME, although we do propose a different
trust model.  We agree that OpenPGP and S/MIME are successful encapsulations,
but we think their trust models are insufficient to achieve ubiquitous mail
encryption.

> Use existing tools most user have installed on his machine by default - work with these and get a suiteable end-to-end encryption going!

I don't know how you suggest this could be done, but I would be very
interested in alternative proposals.

Thanks,
Marcus