STEED - Usable end-to-end encryption

Jerome Baum jerome at
Tue Oct 18 15:30:00 CEST 2011

>> Skimmed over this. You say that you need ISP support to get the 
>> system adopted (for the DNS-based distribution). Wouldn't that 
>> hinder adoption?
> Please look at how most people use mail: They get a mail address from
> their ISP, a preinstalled MUA and so on.  Mail works for them 
> instantly; if it does not work, they change the provider or don't
> use mail.  Thus to allows allow for instant use of encryption it is 
> important to have encryption on by default and so you can't do that 
> without getting ISPs interested in it.

I know a number of "power users" that aren't savvy enough to configure
gpg4win but are savvy enough for their share of MUAs. The MUA in this
case isn't supplied by the ISP.

In fact to my knowledge outside of webmail and inside "private email"
(so drop companies, universities, schools) it's usual to configure your
own MUA, with the help of instructions from your ISP.

So yes the ISP is useful in helping with adoption (never said this isn't
true, I fully agree) but this absolute "ISP or not at all" approach bugs me.

>> How about an opportunistic approach? This email should include the
>>  following header:
> See above.  Further the problem with such headers is that it is a 
> local configuration highly dependent on the used MUA.  More and more 
> users are reading mail with at least two devices.  Thus a certain 
> degree of MUA independence is required.  Access to the DNS is 
> required anyway thus it is an obvious solution to use it for key 
> distribution.

I was saying "if we have to extend the MUA anyway, we might
as well add this header". We have to extend the MUA or otherwise it
doesn't support end-point encryption.

I don't see how DNS changes need to be made "anyway". So take an average
email provider and assume I don't have any zones delegated to me. I can
upload my key to the keyservers just fine. I can add this header just
fine. I can attach the key to my emails just fine. I don't need the ISP
to do anything in his DNS zone.*

(Now before someone comes up with "yeah but the end-user doesn't know
how to", *a computer can do all of this just fine*.)

I'm not saying the ISP wouldn't be helpful when it comes to deploying
this. Using Hushmail is obviously easier than installing and configuring
gpg4win. I just don't like this absolute approach of "we need the ISP,
there's no way to do this without them, so let's not even try." What
speaks against a hybrid approach (use the ISP if they support it, do it
on our own if they don't)?

I'd think what speaks against should be "takes more work to develop" or
"adds software complexity", not theoretical arguments about how this
can't be user-friendly. The "header vs. DNS" question doesn't even
relate to user-friendliness as it should happen behind the scenes. The
only effect cooperation with ISPs would have is that some users get a
message saying we don't support their ISP. I'm trying to suggest a
solution that drop this message for those users.

* To show that I think DNS is useful:


(Hmm I should update that to the https version. I'll do this "tomorrow".)

PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA

More information about the Gnupg-users mailing list