Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: users

STEED - Usable end-to-end encryption

 

 

GnuPG users RSS feed   Index | Next | Previous | View Threaded


wk at gnupg

Oct 17, 2011, 11:11 AM

Post #1 of 80 (6469 views)
Permalink
STEED - Usable end-to-end encryption

Hi!

Over the last year Marcus and me discussed ideas on how to make
encryption easier for non-crypto geeks. We explained our plans to
several people and finally decided to start a project to develop such a
system. Obviously it is based on GnuPG but this is only one component
of the whole system. We prepared a short paper; if you are interested
you may download it from

http://g10code.com/docs/steed-usable-e2ee.pdf

There is also a brief (for now) web page dedicated to this project:

http://g10code.com/steed.html



Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 17, 2011, 11:25 AM

Post #2 of 80 (6374 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

> http://g10code.com/docs/steed-usable-e2ee.pdf

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?
hotmail and the like still don't support POP3 or IMAP in a standard
account, and they are still popular options.

So obviously email providers aren't the right place to look to get a
technology deployed, especially one that hinders their access to email.

How about an opportunistic approach? This email should include the
following header:

OpenPGP: id=C58C753A;
url=https://jeromebaum.com/pgp

The MUA could recognize a header like this one and remember that there's
a certificate -- so the next email we send will be encrypted. The first
email couldn't be, but is that worse than no encryption at all?

Basically something like Strict-Transport-Security.

What do you think?

Like I said this is based on a quick skimming of the paper. Sorry about
the long message.

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg.user at seibercom

Oct 17, 2011, 1:21 PM

Post #3 of 80 (6389 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, 17 Oct 2011 20:25:04 +0200
Jerome Baum articulated:

> 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? hotmail and the like still don't support POP3 or IMAP in a
> standard account, and they are still popular options.

Are you sure about that?

http://windowslivehelp.com/solution.aspx?solutionid=a485233f-206d-491e-941b-118e45a7cf1b

--
Jerry ‚úĆ
GNUPG.user [at] seibercom
_____________________________________________________________________
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


aaron.toponce at gmail

Oct 17, 2011, 1:32 PM

Post #4 of 80 (6380 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, Oct 17, 2011 at 08:25:04PM +0200, Jerome Baum wrote:
> How about an opportunistic approach? This email should include the
> following header:
>
> OpenPGP: id=C58C753A;
> url=https://jeromebaum.com/pgp
>
> The MUA could recognize a header like this one and remember that there's
> a certificate -- so the next email we send will be encrypted. The first
> email couldn't be, but is that worse than no encryption at all?

I like the idea, but how are you setting the header? I see you're using
Thunderbird, and I don't believe that setting that header is part of
Enigmail. Further, it appears your mail isn't signed. Just curious.

--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o
Attachments: signature.asc (0.51 KB)


ben at adversary

Oct 17, 2011, 2:00 PM

Post #5 of 80 (6381 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 18/10/11 7:32 AM, Aaron Toponce wrote:
>
> I like the idea, but how are you setting the header? I see you're
> using Thunderbird, and I don't believe that setting that header is
> part of Enigmail. Further, it appears your mail isn't signed. Just
> curious.

No, but it is part of Thunderbird:

http://kb.mozillazine.org/Custom_headers

The process is even less straight forward than using Enigmail would be
for end users.


Regards,
Ben
Attachments: signature.asc (0.16 KB)


jerome at jeromebaum

Oct 17, 2011, 2:21 PM

Post #6 of 80 (6365 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 2011-10-17 23:00, Ben McGinnes wrote:
> On 18/10/11 7:32 AM, Aaron Toponce wrote:
>>
>> I like the idea, but how are you setting the header? I see you're
>> using Thunderbird, and I don't believe that setting that header is
>> part of Enigmail. Further, it appears your mail isn't signed. Just
>> curious.

I don't sign every email I send. I tend to plug in my reader whenever I
sign something important, and then sign other mails while the reader is
plugged in. The reader wasn't plugged in in this case.

> No, but it is part of Thunderbird:
>
> http://kb.mozillazine.org/Custom_headers
>
> The process is even less straight forward than using Enigmail would be
> for end users.

So enabling _Enigmail_'s "Send 'OpenPGP' header" option is difficult now?

Anyway, my point wasn't that we should use Enigmail. It wasn't that we
should use the OpenPGP header. It was that we should have an optional
header that unobtrusively says "by the way, I support encryption".

However the OpenPGP header is a pretty good start as Enigmail supports
it. Whatever solution we use, it should be default-on. Plus we should
use key-servers as not everyone has a place to upload the key, and it'd
be pretty involved for a "dumb" end-user.

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 17, 2011, 2:41 PM

Post #7 of 80 (6356 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

> http://windowslivehelp.com/solution.aspx?solutionid=a485233f-206d-491e-941b-118e45a7cf1b

Wow, since 2009 (I haven't checked back in a while -- stay clear of
strange hosts like hotmail).

I think the point still stands though. I don't think email providers are
the right place to look for end-to-end encryption technology: Aren't we
trying to _not_ involve the provider in the encryption ("end-point")? Is
it in the interest of the provider that you encrypt your emails? etc.

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Oct 17, 2011, 2:59 PM

Post #8 of 80 (6393 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/17/11 5:21 PM, Jerome Baum wrote:
> So enabling _Enigmail_'s "Send 'OpenPGP' header" option is difficult now?

Unquestionably, indubitably, beyond doubt, *yes*. You are assuming a
level of computer literacy that is beyond 95% of the computing public.
Remember, under 10% of the computing public knows how to use Ctrl-F to
search through a document. [*]

Speaking personally about Enigmail, I routinely get complaints about
Enigmail being broken from people who don't have GnuPG installed,
complaints about Enigmail being too hard to uninstall from people who
have never installed Enigmail (they thought that just by downloading the
.XPI the file was installed automatically), and so forth. All of us on
the Enigmail user-help team have these stories. I'll eat my own hat if
the GnuPG devs don't have their own.

Users aren't stupid, not by any stretch of the imagination. Some of the
worst offenders have been obviously intelligent people who have been
extremely irate about Enigmail, on the grounds that "I'm a freaking
*physician* and I can't understand this, how do you expect regular users
to?!" To them, all I can say is -- it's not about innate intelligence:
it's about whether you possess the skill of computer literacy. We live
in an immensely technological society, and very few people are computer
literate.



[*]
http://www.theatlantic.com/technology/archive/2011/08/crazy-90-percent-of-people-dont-know-how-to-use-ctrl-f/243840/


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 17, 2011, 3:07 PM

Post #9 of 80 (6379 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 2011-10-17 23:59, Robert J. Hansen wrote:
> On 10/17/11 5:21 PM, Jerome Baum wrote:
>> So enabling _Enigmail_'s "Send 'OpenPGP' header" option is difficult now?
>
> [long rant about Enigmail]

The emphasis was clearly on "Enigmail", not on whether it's difficult or
not. If you hadn't misquoted me you might have included the bit where I
said this should be default-on (obviously so the user doesn't have to
configure it).

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


aaron.toponce at gmail

Oct 17, 2011, 4:50 PM

Post #10 of 80 (6354 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, Oct 17, 2011 at 08:25:04PM +0200, Jerome Baum wrote:
> How about an opportunistic approach? This email should include the
> following header:
>
> OpenPGP: id=C58C753A;
> url=https://jeromebaum.com/pgp
>
> The MUA could recognize a header like this one and remember that there's
> a certificate -- so the next email we send will be encrypted. The first
> email couldn't be, but is that worse than no encryption at all?
>
> Basically something like Strict-Transport-Security.
>
> What do you think?
>
> Like I said this is based on a quick skimming of the paper. Sorry about
> the long message.

For the uninitiated, http://josefsson.org/openpgp-header/ explains the
'OpenPGP' header, and it's syntax. This was something new to me. A bit of
additional research on whether or not this was something Mutt was planning
on adding led me to http://marc.info/?l=mutt-dev&m=110227240028896&w=2.

I've added it with "my_hdr OpenPGP id=${pgp_sign_as}\;url=...". The only
question remaining, for me, is whether or not it should be "X-OpenPGP" or
"OpenPGP" as the header field name. I've heard various positions on this,
but nothing definitive.

At any rate, I would love to see more client-to-client encryption in email.
I've always wondered if there could be an "OTR" approach to mail, somehow,
so people don't need to generate and manage their own sets of keys, as that
seems to be the largest hinderence to widespread adoption. The only thing
the user should do, is compose the mail, hit send, and everything is
handled with very minimal user interaction.

--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o
Attachments: signature.asc (0.51 KB)


rjh at sixdemonbag

Oct 17, 2011, 5:27 PM

Post #11 of 80 (6378 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/17/2011 6:07 PM, Jerome Baum wrote:
>>> So enabling _Enigmail_'s "Send 'OpenPGP' header" option is difficult now?
>
> The emphasis was clearly on "Enigmail", not on whether it's difficult or
> not.

And the answer to your question is obviously, "Yes."

> If you hadn't misquoted me you might have included the bit where I
> said this should be default-on (obviously so the user doesn't have to
> configure it).

As soon as you can figure out a way to do this, I'll take it seriously.
Until then, this is magic pixie dust.

Everyone has an idea for how to do this: I've yet to see a single one
that actually stands any chance at success. The more you make the
process automated the more fragile and exploitable it becomes. The more
you shift the burden to people, the better your chances of resistance to
attack but the worse the learning curve and adoption rates become.



_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


wk at gnupg

Oct 17, 2011, 11:46 PM

Post #12 of 80 (6376 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, 17 Oct 2011 20:25, jerome [at] jeromebaum said:

> 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.

> 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.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


simon at josefsson

Oct 18, 2011, 1:24 AM

Post #13 of 80 (6341 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Aaron Toponce <aaron.toponce [at] gmail> writes:

> I've added it with "my_hdr OpenPGP id=${pgp_sign_as}\;url=...". The only
> question remaining, for me, is whether or not it should be "X-OpenPGP" or
> "OpenPGP" as the header field name. I've heard various positions on this,
> but nothing definitive.

No X-OpenPGP please. It was a broken idea that prevented
standardization of headers that gain popularity. The X- idea was
removed from the latest revision of RFC 822.

/Simon

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


melvincarvalho at gmail

Oct 18, 2011, 2:50 AM

Post #14 of 80 (6363 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 17 October 2011 20:11, Werner Koch <wk [at] gnupg> wrote:
> Hi!
>
> Over the last year Marcus and me discussed ideas on how to make
> encryption easier for non-crypto geeks. †We explained our plans to
> several people and finally decided to start a project to develop such a
> system. †Obviously it is based on GnuPG but this is only one component
> of the whole system. †We prepared a short paper; if you are interested
> you may download it from
>
> †http://g10code.com/docs/steed-usable-e2ee.pdf
>
> There is also a brief (for now) web page dedicated to this project:
>
> †http://g10code.com/steed.html

Have you had a look at?

http://retroshare.sourceforge.net/

It has a very good integration with GPG

>
>
>
> Salam-Shalom,
>
> † Werner
>
>
> --
> Die Gedanken sind frei. †Ausnahmen regelt ein Bundesgesetz.
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 18, 2011, 6:30 AM

Post #15 of 80 (6339 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

>> 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:

;; ANSWER SECTION:
jerome._pka.jeromebaum.com. 3596 IN TXT
"v=pka1\;fpr=A0E4B2D494E620EE85BAE45B63E42BD8C58C753A\;uri=http://jeromebaum.com/pgp"

(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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


mwood at IUPUI

Oct 18, 2011, 6:42 AM

Post #16 of 80 (6341 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, Oct 17, 2011 at 05:50:42PM -0600, Aaron Toponce wrote:
[snip]
> At any rate, I would love to see more client-to-client encryption in email.
> I've always wondered if there could be an "OTR" approach to mail, somehow,
> so people don't need to generate and manage their own sets of keys, as that
> seems to be the largest hinderence to widespread adoption. The only thing
> the user should do, is compose the mail, hit send, and everything is
> handled with very minimal user interaction.

"Three can keep a secret, if two of them are dead."

If your computer holds the ultimate secret, anyone who can control the
computer can use that secret. The user *must* be actively involved.
We can remove *needless* complexity, but security could be said to be
the art of *introducing* specific complexity that's a lot worse for
the attacker than it is for you. It can't be automagical.

Anyway, key generation is already automated. All you have to do is
(1) choose to employ crypto, and (2) supply a passphrase that you can
remember. There are even methods and tools to help you do (2)!

To be secure without being involved in the process is an unreasonable
expectation which can never be met. We need to teach our kids to
expect to protect themselves online the same way we teach them to look
both ways before crossing the street. Probably at the same age.
Otherwise they'll grow up to believe the hype that you can buy
security the same as buying bread.

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Asking whether markets are efficient is like asking whether people are smart.


wk at gnupg

Oct 18, 2011, 6:42 AM

Post #17 of 80 (6372 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Tue, 18 Oct 2011 15:30, jerome [at] jeromebaum said:

> 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.

Well, so we need to convince them to change those instructions.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


mwood at IUPUI

Oct 18, 2011, 7:00 AM

Post #18 of 80 (6350 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

I don't see why the ISP has to be the entity providing DNS lookup.
The one I use won't even allocate me a static address, let alone
accept RRs from me to serve out to others. I'm not sure I'd trust
them to get it right and *keep* it right anyway.

If the ISPs won't cooperate, maybe the antivirus vendors would.
They're already in the data security business, already have an
extensive network presence, and already get money from me to help me
secure my information assets. Build enrollment into the AV product or
provide a separate setup tool. It should be simple.

Likewise there are freestanding DNS providers out there who already
have the infrastructure and the experience, are already serving some
of us, already get money from some of us. This could be a welcome
source of a little more income for very little more cost, or a freebie
to get you in the door like free DDNS does.

(I should read the paper; maybe this has been addressed.)

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Asking whether markets are efficient is like asking whether people are smart.


peter at digitalbrains

Oct 18, 2011, 7:30 AM

Post #19 of 80 (6333 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 18/10/11 16:00, Mark H. Wood wrote:
> I don't see why the ISP has to be the entity providing DNS lookup.

Because it is the e-mail address of the recipient you look up; that's all the
data you have in this scenario. Thus, for me you would look up a key
corresponding to user peter at the domain digitalbrains.com. The only logical
place to look for that without further information is in the domain
digitalbrains.com, which is under control of the e-mail provider. ISP here means
e-mail provider, by the way, perhaps that is the confusion. Unless I'm the one
confused ;).

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 18, 2011, 7:35 AM

Post #20 of 80 (6360 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

>> 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.
>
> Well, so we need to convince them to change those instructions.

Yes and this is what I said: It's useful to get the ISP involved. But
it's not necessary -- Google doesn't provide instructions on how to
enable send receipts in Outlook. I would guess that there are users out
there using gmail that use read receipts.

So yes, definitely get the ISPs involved. But let's not rely on them. A
good, easy-to-use (easy-to-install) plugin for Outlook '03/'07/'10
should go a long way to getting people to use end-point encryption.

The main value I would see in the STEED proposal is to make this whole
process easier for the user. The UI for keyring management and crypto
operations will be the most important part to making that work, and the
ISPs don't have to help out there (modulo webmail which isn't even
end-point).

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 18, 2011, 7:39 AM

Post #21 of 80 (6338 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

> ... We can remove *needless* complexity, but security could be said
> to be the art of *introducing* specific complexity that's a lot worse
> for the attacker than it is for you. It can't be automagical.
>
> Anyway, key generation is already automated. All you have to do is
> (1) choose to employ crypto, and (2) supply a passphrase that you
> can remember. There are even methods and tools to help you do (2)!
>
> To be secure without being involved in the process is an
> unreasonable expectation which can never be met. We need to teach
> our kids to expect to protect themselves online the same way we teach
> them to look both ways before crossing the street. Probably at the
> same age. Otherwise they'll grow up to believe the hype that you can
> buy security the same as buying bread.

So let's put up traffic lights to help them and employ some crossing
guards to teach them the first steps until they are old enough to make
their own decisions.

Or put another way, we could make the process automagical until the user
has enough experience with the tool to do this themselves. The question
is whether we should -- false sense of security, "reasonable" threat
model, etc.

Either way, it's better to encrypt to key that you _think_ is the
recipient's key than to none at all*, because now your passive attacker
is helpless.

* Under a specific set of threat models.

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 18, 2011, 7:45 AM

Post #22 of 80 (6327 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

> I don't see why the ISP has to be the entity providing DNS lookup.
> The one I use won't even allocate me a static address, let alone
> accept RRs from me to serve out to others. I'm not sure I'd trust
> them to get it right and *keep* it right anyway.

I should clarify. An email provider is also an ISP, and I was referring
to the email-provider type of ISP. But yes I agree that we shouldn't
trust the ISPs too much and that's why I keep saying we shouldn't rely
solely on them.

> If the ISPs won't cooperate, maybe the antivirus vendors would.
> They're already in the data security business, already have an
> extensive network presence, and already get money from me to help me
> secure my information assets. Build enrollment into the AV product or
> provide a separate setup tool. It should be simple.

This I'm not too sure if we can trust an AV vendor more or less than an
ISP. That's the problem with making these decisions for the user: We're
pushing the trust onto them, just like the CA root certificates in most
browsers.

The trust decision should be with the user. In a user-friendly way.
Also, I want world peace.

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


wk at gnupg

Oct 18, 2011, 8:41 AM

Post #23 of 80 (6360 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Tue, 18 Oct 2011 16:30, peter [at] digitalbrains said:

> Because it is the e-mail address of the recipient you look up; that's all the
> data you have in this scenario. Thus, for me you would look up a key
> corresponding to user peter at the domain digitalbrains.com. The only logical

Right. That is the whole point. We want to make keys invisible. You
can't explain easily why you need a separate public key if you already
have an email address. Thus from the user's point of view the email
address is the public key.

> digitalbrains.com, which is under control of the e-mail provider. ISP here means
> e-mail provider, by the way, perhaps that is the confusion. Unless I'm the one

Sure, email provider. However for most users this is identical to the
ISP: First of all they need a connection to the Internet. Unless you
spend a lot of money for the connections you will get an email address
along with your user identification for DSL access.

The email provider sets up something like /etc/aliases for the mail
address and some of them also enter records into their zone file with
the mailbox name for anti-spam protocols. They need to enter yet
another record into a zone file to allow a key lookup by the assigned
mail address.


Salam-Shalom,

Werner



_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


wk at gnupg

Oct 18, 2011, 8:58 AM

Post #24 of 80 (6358 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Tue, 18 Oct 2011 15:42, mwood [at] IUPUI said:

> To be secure without being involved in the process is an unreasonable
> expectation which can never be met. We need to teach our kids to
> expect to protect themselves online the same way we teach them to look

We did this for about 15 years - without any success. If you look at
some of the studies you will see that you can't teach that stuff to
non-techies - sometimes not even to engineers.

Let's compare it using an example from the not too far past: It has been
claimed that most VCRs used to blink 12:00 but nevertheless they were
sold and did what they should do: tape movies. This is similar to mail:
Everyone is able to send and receive mail but most are not able to (set
the VCR timer|encrypt the mails). Newer features in VCRs set the clock
automatically and make the timer setting task much easier in the user
interface (e.g. by selecting the title of the movie you want to tape
from a electronic program magazine). This user experience is what we
need to aim for.

> both ways before crossing the street. Probably at the same age.

That is easy because we have learned over thousands of years to use our
senses to be safe. Our senses for those small electrons are not as
matured as the the others. Why should they - we know about them only
for maybe 300 years.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


wk at gnupg

Oct 18, 2011, 9:00 AM

Post #25 of 80 (6341 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Tue, 18 Oct 2011 16:35, jerome [at] jeromebaum said:

> operations will be the most important part to making that work, and the
> ISPs don't have to help out there (modulo webmail which isn't even
> end-point).

Even webmail. It is easy to write a browser extension to do the crypto
stuff. Installing browser extensions is even easier than installing
most other software.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 18, 2011, 9:16 AM

Post #26 of 80 (4296 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

> Even webmail. It is easy to write a browser extension to do the crypto
> stuff. Installing browser extensions is even easier than installing
> most other software.

I'd make it a point of discussion whether it's still webmail proper then.

But you could also use Javascript, Java or Flash, so yes this is doable
for webmail. I wouldn't trust my ISP to deliver the encryption module
though. It kind of defeats the "end-point" part in "end-point
encryption". As your average user I have no way to verify the module and
nobody can vouch for it as it's dynamically updated by my ISP.

So a fixed, open-source browser extension is really the only way to do
this properly. How is this different from installing an MUA (given that
a browser extension is often a full-blown piece of software with full
rights to the system)?

With the webmail argument and since webmail is probably majority access
for private email, it's looking more important to work with the ISPs,
but I stand by my point of not building this on a single pillar.

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Oct 18, 2011, 9:18 AM

Post #27 of 80 (4270 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/18/2011 11:58 AM, Werner Koch wrote:
> We did this for about 15 years - without any success. If you look
> at some of the studies you will see that you can't teach that stuff
> to non-techies - sometimes not even to engineers.

As a data point from 2005:

I was teaching computer literacy at the University of Iowa. The first
day of class I asked the 35 students which of them brought a computer of
any kind to class. Three people raised their hands: they all said they
brought laptops. When I asked how many brought cell phones, all 35
raised their hands. The only people who thought cell phones were
computers were the three who brought laptops.

I then asked if a game console (XBox, Playstation, take your pick) was a
computer. The class was almost evenly split: half said yes, on account
of how you could surf the web with it. Half said no, because you can't
write a Word document with it.

Admittedly, this is not a representative sample of college students.
That said, I think it's an informative anecdote.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


holtzm at cox

Oct 18, 2011, 11:50 AM

Post #28 of 80 (4274 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, Oct 17, 2011 at 05:50:42PM -0600, Aaron Toponce wrote:

.........snip..........
>
> At any rate, I would love to see more client-to-client encryption in email.
> I've always wondered if there could be an "OTR" approach to mail, somehow,
> so people don't need to generate and manage their own sets of keys, as that
> seems to be the largest hinderence to widespread adoption.
> the user should do, is compose the mail, hit send, and everything is

Not true. The greatest hindrance to widespread adoption is the phrase I
often hear..."I've got nothing to hide" It drives me up a wall.


> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


--
Bob Holtzman
If you think you're getting free lunch,
check the price of the beer.
Key ID: 8D549279
Attachments: signature.asc (0.19 KB)


gollo at fsfe

Oct 18, 2011, 12:59 PM

Post #29 of 80 (4275 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

* Robert Holtzman <holtzm [at] cox> [111018 21:43,
mID <20111018185035.GB4590 [at] cox>]:

> The greatest hindrance to widespread adoption is the phrase I often
> hear..."I've got nothing to hide" It drives me up a wall.

+1

Martin
Attachments: smime.p7s (3.96 KB)


yyy at yyy

Oct 19, 2011, 1:20 AM

Post #30 of 80 (4280 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

----- Original Message -----
From: "Werner Koch" <wk [at] gnupg>
To: "Jerome Baum" <jerome [at] jeromebaum>
Cc: <gnupg-users [at] gnupg>
Sent: Tuesday, October 18, 2011 7:00 PM
Subject: Re: STEED - Usable end-to-end encryption


> On Tue, 18 Oct 2011 16:35, jerome [at] jeromebaum said:
>
>> operations will be the most important part to making that work, and the
>> ISPs don't have to help out there (modulo webmail which isn't even
>> end-point).
>
> Even webmail. It is easy to write a browser extension to do the crypto
> stuff. Installing browser extensions is even easier than installing
> most other software.
>
There is firegpg plugin for firefox, and it does not works well with
latest versions (installing it in firefox5 was not straightforward).
I am not aware of any other public key encryption plugin
for firefox or for any other browser. Some webmails have
POP3/IMAP/SMTP, but some does not. (for example inbox.lv
for qute long time had only POP3, but not SMTP)

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


tom at ritter

Oct 19, 2011, 6:11 AM

Post #31 of 80 (4308 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 18 October 2011 12:00, Werner Koch <wk [at] gnupg> wrote:
> On Tue, 18 Oct 2011 16:35, jerome [at] jeromebaum said:
>
>> operations will be the most important part to making that work, and the
>> ISPs don't have to help out there (modulo webmail which isn't even
>> end-point).
>
> Even webmail. †It is easy to write a browser extension to do the crypto
> stuff. †Installing browser extensions is even easier than installing
> most other software.


It's not easy. I'm aware of FireGPG, CR-GPG, and Penango and they
range from non-functional to barely-functional, some of the time.

Email encryption is a super-hard problem because even within a 'target
audience', you have to deal with hard problems, and
cross-target-audience they get even harder.

The Young Crowd: Most people I know use gmail web interface and their phone.
The Old Crowd: Most of these folks I know use yahoo, hotmail, or their
ISP with Outlook Express.
The Super-Old-Crowd: Anything, but it needs to be easy enough to set
up that a member of the Old Crowd can do it *for* a member of this
crowd.
Corporate: It has to enterprise manageable, key escrow, compliant, etc
Devs/Security Folks: Key Management! My private key can never leave my
possession.
Other Security Folks: Absolutely NO javascript cryptography. Zero, none.

And there's the very practical problem of _sometimes_ I do need to
read my mail from a machine that is not my own. As a security person
I almost never do it. But 'the young crowd' do it all the time. You
have to satisfy that requirement also.

>From what I've seen - S/MIME within an organization satisfies most of
Corporate, until you send an email outside the organization. Enigmail
satisfies some developers/security folk (but you lose email on your
phone and webmail - which is pretty nice.)

Any solution you come up with for one group _should_ interoperate with
the solution(s) for the others.

And any solution that relies on an ISP or webmail provider making
changes is just unlikely. The most innovation we've seen recently has
come from the Chrome and Mozilla teams who are driving browser
security with HSTS, Pinning, and Content Security Policy. Internet
Explorer is driving browser security in another direction with
reputational-based downloads and anti-phishing.

So trying to drive a secure, browser-based cryptoapi seems to be a
reasonable possibility. (See DOMCrypt). For browsers without the
API, you could use a plugin to provide it, and eventually hopefully
the browser makes it part of the browser proper and the extension is
obsolete.
That almost solves webmail. Except that the provider needs to support
it - and you could opt to leave your key on the server vs not, that
partially solves key management (because it's a choice). It could use
OpenPGP and interoperate with Enigmail/Mutt. But you're still left
trying to interoperate with corporate, phone-mail, convincing
yahoo/hotmail/other obscure webmails to support it, intergrating it
into the next Outlook Express ("Windows Mail" I think?), and having an
understandable UI.

I've been working with and on remailers recently, and this is a
similar problem. It's bloody hard. I don't know if there will ever
be a better solution than what we have now, and what we have now
sucks.

-tom

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


alex at gpgtools

Oct 19, 2011, 7:46 AM

Post #32 of 80 (4268 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Hi,

On 19.10.2011, at 15:11, Tom Ritter wrote:
> Other Security Folks: Absolutely NO javascript cryptography. Zero, none.

well, JavaScript itself is just another programming language and combined with modern technologies like HTML5 Web Storage there is nowadays technically no need to implement browser plugins for different versions and platforms. See [1].

Best regards, Alex

[1] http://www.gpgtools.org/mobile/index.html

--
http://gpgtools.org


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


harakiri_23 at yahoo

Oct 19, 2011, 11:07 AM

Post #33 of 80 (4267 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

--- On Mon, 10/17/11, Werner Koch <wk [at] gnupg> wrote:

> From: Werner Koch <wk [at] gnupg>
> Subject: STEED - Usable end-to-end encryption
> To: gnupg-devel [at] gnupg
> Cc: "Marcus Brinkmann" <marcus [at] gnu>, gnupg-users [at] gnupg
> Date: Monday, October 17, 2011, 2:11 PM
> Hi!

>
> † http://g10code.com/docs/steed-usable-e2ee.pdf
>
> There is also a brief (for now) web page dedicated to this
> project:
>
> † http://g10code.com/steed.html

Here is some input, you might not like it - but still:

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?

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...

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.

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

Oct 19, 2011, 12:30 PM

Post #34 of 80 (4278 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Werner, Marcus,

Thank you for thinking about taking end-to-end e-mail encryption to the next
level. I really like your ideas.

However, I think you're not ambitious enough when you opt for using DNS for key
distribution. Yes, the infrastructure and RR types[1] are already there. But it
brings this nasty dependency on the provider. Because the part of the client
updates to the DNS is a key missing part in the DNS infrastructure as today, and
I don't see providers adding that soon.

I'm thinking more of things like DHT, Distributed Hash Tables, in BitTorrent, or
similar concepts in other peer-to-peer networks. I have no idea how it works :),
but it does. You fire up your BitTorrent, all the data it needs is the hash of a
torrent file, and suddenly it learns IP-addresses of other people who share that
torrent file. If you could do something similar for mapping e-mail addresses to
certificates, you don't need ISP's to implement extra stuff. Because I think
that is a really major hurdle; probably a too steep one, IMHO.

And if you design that infrastructure general enough to do X-to-certificate, we
could use the same infra for opportunistic end-to-end encryption of TCP/IP,
which would be great to have too, but a different paper altogether :).

Peter.

[1] "Entries" in the DNS, for people not up to DNSpeed ;)
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

Oct 19, 2011, 12:40 PM

Post #35 of 80 (4292 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 19/10/11 21:30, Peter Lebbing wrote:
> that is a really major hurdle; probably a too steep one, IMHO.

Given that all normal, literal hurdles are at right angles to the ground, they
are all equally steep. Obviously I meant high :D.

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


expires2011 at ymail

Oct 19, 2011, 1:03 PM

Post #36 of 80 (4302 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Wednesday 19 October 2011 at 7:07:45 PM, in
<mid:1319047665.75751.YahooMailClassic [at] web130223>,
Harakiri wrote:


> 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.

On the other hand, perhaps the message to take from the current low
adoption levels of encrypted email is that the current protocols need
replacing (or major tweaking). (-;



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

If tools are installed by default but not enabled by default, maybe
the group that needs bringing on board is not ISPs/email providers but
OEMs and those who produce operating systems, email clients and
browsers?


- --
Best regards

MFPA mailto:expires2011 [at] ymail

What's another word for synonym?
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTp8tQ6ipC46tDG5pAQojwQQAyVC7lwcAqp82tR9lwxLQ2Y5bfdmw0Fym
yYD/xnFlEB2Pxyzsvizdb0SyCgrGlpqIePhCw8YqGMW6ZWVl+l1Q3mU3SI67G+db
s74vMtMLVr2zMW7FiGfKpHrDad6Gj1RQHoBSjN4kmalcTEGMediABmXgwFrfk9le
/Ze5URFyJj4=
=V8zt
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


smujohnson at gmail

Oct 19, 2011, 1:09 PM

Post #37 of 80 (4270 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Hi,

I read this briefly, and I'd actually like to read it over later and maybe
contribute some ideas. The lack of people caring about cryptography is
quite apparent, and may be solved with some good ideas of making things less
annoying / hard to use.

I'd be happy to help.


On Mon, Oct 17, 2011 at 11:11 AM, Werner Koch <wk [at] gnupg> wrote:

> Hi!
>
> Over the last year Marcus and me discussed ideas on how to make
> encryption easier for non-crypto geeks. We explained our plans to
> several people and finally decided to start a project to develop such a
> system. Obviously it is based on GnuPG but this is only one component
> of the whole system. We prepared a short paper; if you are interested
> you may download it from
>
> http://g10code.com/docs/steed-usable-e2ee.pdf
>


kloecker at kde

Oct 19, 2011, 1:10 PM

Post #38 of 80 (4288 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Wednesday 19 October 2011, Harakiri wrote:
> --- On Mon, 10/17/11, Werner Koch <wk [at] gnupg> wrote:
> > From: Werner Koch <wk [at] gnupg>
> > Subject: STEED - Usable end-to-end encryption
> > To: gnupg-devel [at] gnupg
> > Cc: "Marcus Brinkmann" <marcus [at] gnu>, gnupg-users [at] gnupg
> > Date: Monday, October 17, 2011, 2:11 PM
> > Hi!
> >
> >
> > http://g10code.com/docs/steed-usable-e2ee.pdf
> >
> > There is also a brief (for now) web page dedicated to this
> > project:
> >
> > http://g10code.com/steed.html
>
> Here is some input, you might not like it - but still:
>
> 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?
>
> 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.

No, it does not. At least, not by default. If you buy a qualified
certificate then you can put this certificate on your "Personalausweis",
but, given how expensive such a certificate is, I doubt that a lot of
people will use this feature of the Personalausweis. There are probably
more people with an OpenPGP-capable smartcard than there are people with
a German Personalausweis with an expensive certificate.


> Other european countries could follow...
>
> 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.

What NEW standard are you talking about? Werner wants to use OpenPGP.
The only thing he wants to simplify is key exchange.


> 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'm not sure what existing tools you mean. Are you talking about S/MIME?
You said yourself that S/MIME is no viable solution because of
compatibility issues.


Regards,
Ingo
Attachments: signature.asc (0.19 KB)


expires2011 at ymail

Oct 19, 2011, 1:18 PM

Post #39 of 80 (4278 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Wednesday 19 October 2011 at 8:30:48 PM, in
<mid:4E9F2568.6080709 [at] digitalbrains>, Peter Lebbing wrote:


> If you could do something similar for
> mapping e-mail addresses to certificates

It would be awesome if this could be achieved without revealing other
email addresses or UIDs that might happen to map to the same
key/certificate.


- --
Best regards

MFPA mailto:expires2011 [at] ymail

Did you hear? They took the word gullible out of the dictionary
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTp8whKipC46tDG5pAQosxQP9GrQFRgLGah55Xn3wtD1yOs1LfSiodMxu
t4pEi3ecFQPrVvhExXhaqqm2MnDk14CG6xonZorMbrOc++oPqaismQ1ZCOagHiU0
Klqy3k/S0sWR2XIK7ec9G4BRNUirKtsIA4Etj0BXyfbuuDZ0weWxFPelZ5VBD6Ow
ZLQ+joDgtdk=
=iWzE
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 19, 2011, 1:22 PM

Post #40 of 80 (4273 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

>> If you could do something similar for
>> mapping e-mail addresses to certificates
>
> It would be awesome if this could be achieved without revealing other
> email addresses or UIDs that might happen to map to the same
> key/certificate.

Hash the UID many times. (Didn't someone propose that a while ago?)

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

Oct 19, 2011, 1:49 PM

Post #41 of 80 (4275 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 19/10/11 22:22, Jerome Baum wrote:
>> It would be awesome if this could be achieved without revealing other
>> email addresses or UIDs that might happen to map to the same
>> key/certificate.
>
> Hash the UID many times. (Didn't someone propose that a while ago?)

By default the STEED system as proposed creates a new certificate for every
e-mail address. So unless manually overridden, there is a one-to-one relation
between e-mail addresses and certificates and no way to "enumerate all e-mail
addresses".

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 19, 2011, 1:54 PM

Post #42 of 80 (4277 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 2011-10-19 22:49, Peter Lebbing wrote:
> On 19/10/11 22:22, Jerome Baum wrote:
>>> It would be awesome if this could be achieved without revealing other
>>> email addresses or UIDs that might happen to map to the same
>>> key/certificate.
>>
>> Hash the UID many times. (Didn't someone propose that a while ago?)
>
> By default the STEED system as proposed creates a new certificate for every
> e-mail address. So unless manually overridden, there is a one-to-one relation
> between e-mail addresses and certificates and no way to "enumerate all e-mail
> addresses".
>
> Peter.
>

Re-reading the original quote ("map to the same key/certificate") that's
right. I had assumed he was talking about the DHT correlating keys (so
just like you can tell in the BitTorrent DHT which other torrents some
IP is involved in by doing enough work, you might be able to tell which
other certificates that IP uploaded -- but all this is nonsense in the
original context, which I misread).

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

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


hka at qbs

Oct 19, 2011, 2:06 PM

Post #43 of 80 (4292 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Wednesday 19 of October 2011 22:10:30 Ingo Klöcker wrote:
> On Wednesday 19 October 2011, Harakiri wrote:
> >
> > 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.
>
> What NEW standard are you talking about? Werner wants to use OpenPGP.
> The only thing he wants to simplify is key exchange.

since when key servers are hard to use? the short PGP fingerprints can easily
be told on the phone (so you have a voice verification of the key if you know
the person) and the full can be verified just as easily.

The problem is that people don't feel the need for authentication and privacy
in e-mail. They feel that e-mail is secure (after all I use encryption to my
e-mail server).

Regards,
--
Hubert Kario

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


expires2011 at ymail

Oct 19, 2011, 2:36 PM

Post #44 of 80 (4270 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Wednesday 19 October 2011 at 9:49:20 PM, in
<mid:4E9F37D0.50601 [at] digitalbrains>, Peter Lebbing wrote:



> By default the STEED system as proposed creates a new
> certificate for every e-mail address. So unless
> manually overridden, there is a one-to-one relation
> between e-mail addresses and certificates and no way to
> "enumerate all e-mail addresses".

Fair enough if you are using the default. The paper also mentions "One
Key for all Accounts" and says "The system should allow for this use
case, which needs to be supported by all clients by allowing
previously created keys to be conÔ¨Āgured and deployed with an account."

- --
Best regards

MFPA mailto:expires2011 [at] ymail

Wait. You think I'm right?
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTp9C5qipC46tDG5pAQot2wP9Hon1hAbbLzbYo02qBgaW1UZHA/GBBFgH
+t77FNBc3OaolffxGzAZol9FhT+wrzsKkn6yos6E+Ub+rvZHHFgyNGoPPt5WSsBI
U0gfK/is3xBVcmsM8YdWBYcd3l2dQeMyP3tw3CxHCU3DaDUjsjC9+kC3mJ3+E/g5
qjasVBWBFuU=
=m9sn
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


marcus.brinkmann at ruhr-uni-bochum

Oct 19, 2011, 7:16 PM

Post #45 of 80 (4287 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Hi Peter,

thanks for your feedback.

On 10/19/2011 09:30 PM, Peter Lebbing wrote:
> However, I think you're not ambitious enough when you opt for using DNS for key
> distribution. Yes, the infrastructure and RR types[1] are already there. But it
> brings this nasty dependency on the provider. Because the part of the client
> updates to the DNS is a key missing part in the DNS infrastructure as today, and
> I don't see providers adding that soon.

You are right that it is a challenge to get the support in the providers, but
note that changes in the mail client are required anyway. Sure, changing the
client and changing the DNS infrastructure are two different kind of beasts,
but we probably can not do without the providers completely if we want
ubiquitous support.

> I'm thinking more of things like DHT, Distributed Hash Tables, in BitTorrent, or
> similar concepts in other peer-to-peer networks. I have no idea how it works :),
> but it does. You fire up your BitTorrent, all the data it needs is the hash of a
> torrent file, and suddenly it learns IP-addresses of other people who share that
> torrent file. If you could do something similar for mapping e-mail addresses to
> certificates, you don't need ISP's to implement extra stuff. Because I think
> that is a really major hurdle; probably a too steep one, IMHO.

Yes, P2P networks are great, let's do more of those. But why stop at
certificates? Just use a P2P network for all of DNS.

See what happened? I just turned it around. :)

The paper notes how we can utilize DNSSEC to strengthen our trust model.
Similarly, we can utilize a P2P based DNS system. Now instead of one problem,
we got two :)

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.

Thanks,
Marcus

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


lists-gnupgdev at lina

Oct 19, 2011, 8:30 PM

Post #46 of 80 (4275 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Am 20.10.2011 04:16, schrieb Marcus Brinkmann:
> You are right that it is a challenge to get the support in the providers

the lowest efford are discovery via personal web pages like doing XDR or
maybe webfinger. Most users wont be able to have special RRs - not even
for their own domains (which is also rather seldom).

I would use <link rel=""> like openID does.

Gruss
Bernd


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


wk at gnupg

Oct 20, 2011, 2:04 AM

Post #47 of 80 (4262 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Thu, 20 Oct 2011 05:30, lists-gnupgdev [at] lina said:

> the lowest efford are discovery via personal web pages like doing XDR or
> maybe webfinger. Most users wont be able to have special RRs - not even

Most users don't have personal web pages. So what now? Well many users
have a facebook page - but this would make facebook mandatory and we
woold need support from them (at least to guarantee that they don't
break any assumptions). Not much different to work with ISPs.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


wk at gnupg

Oct 20, 2011, 2:26 AM

Post #48 of 80 (4287 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Wed, 19 Oct 2011 22:10, kloecker [at] kde said:

> What NEW standard are you talking about? Werner wants to use OpenPGP.

and S/MIME! We actually don't care. For certain MUAs it is much
simpler to implement something on top of S/MIME than to trying to get
OpenPGP support. The actual protocol in use does not matter to the user
(only to use experts).


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


mwood at IUPUI

Oct 20, 2011, 6:56 AM

Post #49 of 80 (4272 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

What proportion of consumer-grade ISPs have bothered to implement
DNSSEC for serving their customers? I don't think mine does, and
they're a big outfit. If I asked, I expect they'd think I was
speaking Aldebaranese or something.

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Asking whether markets are efficient is like asking whether people are smart.


ott at mirix

Oct 20, 2011, 1:25 PM

Post #50 of 80 (4256 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Thu, Oct 20, 2011 at 04:16:01AM +0200, Marcus Brinkmann wrote:
> On 10/19/2011 09:30 PM, Peter Lebbing wrote:
> > However, I think you're not ambitious enough when you opt for using DNS for key
> > distribution. Yes, the infrastructure and RR types[1] are already there. But it
> > brings this nasty dependency on the provider. Because the part of the client
> > updates to the DNS is a key missing part in the DNS infrastructure as today, and
> > I don't see providers adding that soon.
>
> You are right that it is a challenge to get the support in the providers, but
> note that changes in the mail client are required anyway. Sure, changing the
> client and changing the DNS infrastructure are two different kind of beasts,
> but we probably can not do without the providers completely if we want
> ubiquitous support.

But who are the providers? Except for people who work in computer
science, physics or similar fields I don't know people who run their own
mail servers or are part of a cooperative. Most other people use a
handful of providers who often offer free service in exchange for the
loss of privacy or at least some form of semi-targeted advertisement. Do
you expect those providers to ruin their business models by implementing
this proposal? I wouldn't count on them.

Perhaps the providers could also be forced by law not to implement
this, because (if I remember correctly) come countries require that
they store at least the header information (including subject, which
should also be encryted by the system) for traffic analysis. So in
the worst case the providers couldn't implement this without breaking
the law (I doubt that citizens could use the system without breaking the
law in this situation either, but individuals are often more venturous
than organisations).

What about making everyone their own provider? The efforts in this
direction intiated by Eben Moglen that lead to the FreedomBox and other
projects seem to go in the right direction. It doesn't seem to me less
realistic than requiring cooperation from providers.

Regards,
Matthias-Christian

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


marcus.brinkmann at ruhr-uni-bochum

Oct 20, 2011, 4:46 PM

Post #51 of 80 (2766 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/20/2011 10:25 PM, Matthias-Christian Ott wrote:
> But who are the providers? Except for people who work in computer
> science, physics or similar fields I don't know people who run their own
> mail servers or are part of a cooperative. Most other people use a
> handful of providers who often offer free service in exchange for the
> loss of privacy or at least some form of semi-targeted advertisement. Do
> you expect those providers to ruin their business models by implementing
> this proposal? I wouldn't count on them.

Maybe. But the only way to fail for certain is by not trying. There are
other business models and market pressures beside those that you are
highlighting. It's not easy to predict.

> Perhaps the providers could also be forced by law not to implement
> this, because (if I remember correctly) come countries require that
> they store at least the header information (including subject, which
> should also be encryted by the system) for traffic analysis. So in
> the worst case the providers couldn't implement this without breaking
> the law (I doubt that citizens could use the system without breaking the
> law in this situation either, but individuals are often more venturous
> than organisations).

STEED is fully compatible with existing mail encryption, so we do not include
the headers in the plaintext. I am not an expert, but as far as I know the
regulation usually demands to store connection data that is available, it does
not ask for data that is not available for whatever reason. I think your
interpretation of the regulations in that area is overly pessimistic, but I
could be wrong. Maybe you can verify this?

> What about making everyone their own provider? The efforts in this
> direction intiated by Eben Moglen that lead to the FreedomBox and other
> projects seem to go in the right direction. It doesn't seem to me less
> realistic than requiring cooperation from providers.

I think everybody deserves private email communication, not only those who are
willing to be their own provider. We don't expect people to carry out their
own snail mail letters either, and the business model of the post office does
not require spying on the letters.

Now, it may be the case that the freedom box is (or will be) a more attractive
way for people to do email, and everybody will use it and nobody will use
proprietary email service providers. That would be excellent! The FreedomBox
project is a very important project, and it deserves our strongest support
possible. If it is a better alternative, we still need to convince the
FreedomBox project to adopt the STEED proposal (not a single word in the paper
would have to change). And I agree that this is an overall more appealing
task than trying to convince the proprietary providers.

But, we have to go where the users are, and we have to try our best to get the
providers cooperation. There is no benefit in ignoring them and their users
just for our convenience.

If this is too daunting for you, please remember that we do not have to get
their active cooperation. If they accept it grudgingly because not following
along would be bad business (or illegal), then that's good enough. That
requires that we raise the state of the art in the field.

Maybe you are still not convinced. Then let me give you an illustrative
analogy. (Disclaimer: I am not associated with SawStop or anybody involved,
nor have I met anybody involved or used their product). An inventor created a
table saw that can prevent injury by stopping the blade as soon as it is
touched by human flesh ("SawStop"). According to the inventory, he could not
get the technology to be marketed by the big table saw companies. His claim
is that the companies think that by raising the safety measures in the table
saw, they would be more liable for table saw accidents, which would make them
subject to litigation. Eventually he created his own SawStop product line.
Now, after several years, lawmakers and regulators have taken notice and might
make sawstop like technology mandatory in table saws.

Now, maybe SawStop is bad technology, maybe it's good. But at least something
is true: As long as no candidate technology like it exists, the question
doesn't even come up. That's the state we are at with email encryption.
Everybody who tried has learned that email encryption is not worth the hassle.
Everybody who hasn't tried just expects email to be secure and might not even
be aware that it is not. It's time to change that equation, don't you think?

The good news is that STEED will integrate extremely well in P2P systems. The
dependency on a provider in STEED is not integral to the proposal, but just a
consequence of people already relying on their providers infrastructure for
everything else. If users use different infrastructure, STEED will also work
over that infrastructure just as well.

Thanks,
Marcus

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


wk at gnupg

Oct 21, 2011, 1:14 AM

Post #52 of 80 (2782 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Fri, 21 Oct 2011 01:46, marcus.brinkmann [at] ruhr-uni-bochum said:

> not ask for data that is not available for whatever reason. I think your
> interpretation of the regulations in that area is overly pessimistic, but I
> could be wrong. Maybe you can verify this?

Actually the German Federal commissioner for data protection demands the
use of strong encryption. According to him the message-escrow-able
de-mail.de law and services are not suitable for private messages. [1]



Salam-Shalom,

Werner


[1] In German:
<http://www.bfdi.bund.de/DE/Oeffentlichkeitsarbeit/Pressemitteilungen/2011/12_InkrafttretenDEMailGesetz.html?nn=408908>


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


johanw at vulcan

Oct 21, 2011, 5:21 AM

Post #53 of 80 (2776 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 20-10-2011 22:25, Matthias-Christian Ott wrote:

> What about making everyone their own provider?

Is that technically equivalent to running your own mailserver? Because
that also gives some problems: I run my own server at vulcan.xs4all.nl
(bsmtp at a subdomain of my provider) but get some mails bounced because
of ecessive anti-spam filters that complain about no reverse DNS.

--
Met vriendelijke groet / With kind regards,
Johan Wevers

PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jeandavid8 at verizon

Oct 21, 2011, 7:12 AM

Post #54 of 80 (2785 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Matthias-Christian Ott wrote:

>
> What about making everyone their own provider? The efforts in this
> direction intiated by Eben Moglen that lead to the FreedomBox and other
> projects seem to go in the right direction. It doesn't seem to me less
> realistic than requiring cooperation from providers.
>
I was my own provider for many years, and that was easy enough. I got a
static IP address from my ISP for $10/month and ran sendmail as my MTA.
I used mutt am MUA.

But when I switched to Verizon as ISP in order to get FiOS, they wanted
$150/month for a static IP address and an additional fee (I forget what
it was) to be allowed to run sendmail as a server.

Verizon is a great ISP 8-( They discontinued Usenet, so I have to pay a
fee to another provider to use Usenet. They did not reduce their fees
when the reduced the level of service. Greed and Profit before Service:
it is the American way. 8-(

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 10:05:01 up 19:11, 4 users, load average: 4.93, 4.98, 5.11

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


christophe.brocas at cnamts

Oct 21, 2011, 7:22 AM

Post #55 of 80 (2843 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Le 21/10/2011 16:12, Jean-David Beyer a écrit :
> Matthias-Christian Ott wrote:
>
>> What about making everyone their own provider? The efforts in this
>> direction intiated by Eben Moglen that lead to the FreedomBox and other
>> projects seem to go in the right direction. It doesn't seem to me less
>> realistic than requiring cooperation from providers.
>>
> I was my own provider for many years, and that was easy enough. I got a
> static IP address from my ISP for $10/month and ran sendmail as my MTA.
> I used mutt am MUA.
>
> But when I switched to Verizon as ISP in order to get FiOS, they wanted
> $150/month for a static IP address and an additional fee (I forget what
> it was) to be allowed to run sendmail as a server.
>
> Verizon is a great ISP 8-( They discontinued Usenet, so I have to pay a
> fee to another provider to use Usenet. They did not reduce their fees
> when the reduced the level of service. Greed and Profit before Service:
> it is the American way. 8-(
>
Whaou ...

In France, the second ISP (http://www.free.fr/ ) gives a static IP by default
with port filtering and no bandwith usage limit.

BR
Christophe



*****************************************************
"Le contenu de ce courriel et ses éventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire.

Attention : L'organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'organisme sauf s'il en est disposé autrement dans le présent courriel."
******************************************************

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


expires2011 at ymail

Oct 21, 2011, 10:55 AM

Post #56 of 80 (2753 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Thursday 20 October 2011 at 10:04:15 AM, in
<mid:87hb34xcds.fsf [at] vigenere>, Werner Koch wrote:


> Most users don't have personal web pages. So what now?
> Well many users have a facebook page - but this would
> make facebook mandatory and we woold need support from
> them (at least to guarantee that they don't break any
> assumptions). Not much different to work with ISPs.

If you are trying to get people to think about privacy, maybe
suggesting Diaspora as an alternative to Facebook is a direction to
consider...


- --
Best regards

MFPA mailto:expires2011 [at] ymail

War is a matter of vital importance to the State.
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTqGyM6ipC46tDG5pAQr6+AP/dG6q9Z58HD7RVZI5h1EYEA6yDZ2Rfx/p
9zLGMKGh2QY1gYpBqG70g78IZnk01aG62MIALmRReHs6plqR7fjnASZZikItZDQY
IdG8J6B7yCVdA39phiABYoVbIDYeInyxJzMIWDVUDp1gyEYN55CVRmYUO1QslsuV
2VVad3uNL2c=
=wf9G
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


ott at mirix

Oct 23, 2011, 9:50 AM

Post #57 of 80 (2762 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Fri, Oct 21, 2011 at 01:46:02AM +0200, Marcus Brinkmann wrote:
> On 10/20/2011 10:25 PM, Matthias-Christian Ott wrote:
> > But who are the providers? Except for people who work in computer
> > science, physics or similar fields I don't know people who run their own
> > mail servers or are part of a cooperative. Most other people use a
> > handful of providers who often offer free service in exchange for the
> > loss of privacy or at least some form of semi-targeted advertisement. Do
> > you expect those providers to ruin their business models by implementing
> > this proposal? I wouldn't count on them.
>
> Maybe. But the only way to fail for certain is by not trying. There are
> other business models and market pressures beside those that you are
> highlighting. It's not easy to predict.

I agree, there are other business models and perhaps there will be
demand for this, but I just summarised the service providers almost all
‚Äúnon-technical‚ÄĚ people I communicate with use.

> > Perhaps the providers could also be forced by law not to implement
> > this, because (if I remember correctly) come countries require that
> > they store at least the header information (including subject, which
> > should also be encryted by the system) for traffic analysis. So in
> > the worst case the providers couldn't implement this without breaking
> > the law (I doubt that citizens could use the system without breaking the
> > law in this situation either, but individuals are often more venturous
> > than organisations).
>
> STEED is fully compatible with existing mail encryption, so we do not include
> the headers in the plaintext. I am not an expert, but as far as I know the
> regulation usually demands to store connection data that is available, it does
> not ask for data that is not available for whatever reason. I think your
> interpretation of the regulations in that area is overly pessimistic, but I
> could be wrong. Maybe you can verify this?

I'm not aware of any overview of e-mail data rentention, so I don't
have complete picture, but a quick search on EU data retention laws
showed that only SMTP envelope data is officially stored, so at least
in these countries it's not a problem (though I think the subject
should be encrypted as well). Moreover, I agree that as long as the
body and thus the actual contents are not stored there is reason
why a provider could break the law by providing STEED services to
their costumers. Fortunately many countries have laws to garantuee
(at leas in theory) privacy of correspondance and these laws of a
long tradition, so it seems hard to abolish them. However, I see the
possibility that providers could be forced to cooperate with government
agencies, but this would have little impact and would require bigger
efforts to ‚Äúbreak‚ÄĚ STEED this way (e.g. MITM attacks by publishing
false keys for new contacts).

> > What about making everyone their own provider? The efforts in this
> > direction intiated by Eben Moglen that lead to the FreedomBox and other
> > projects seem to go in the right direction. It doesn't seem to me less
> > realistic than requiring cooperation from providers.
>
> I think everybody deserves private email communication, not only those who are
> willing to be their own provider. We don't expect people to carry out their
> own snail mail letters either, and the business model of the post office does
> not require spying on the letters.

I agree, but I also talked to people who don't care about privacy
(nothing to hide) and don't understand it. Therefore, it is important
not to rely on the market to provide the means for private e-mail
communication (do it yourself instead of relying on other people to do
it).

> But, we have to go where the users are, and we have to try our best to get the
> providers cooperation. There is no benefit in ignoring them and their users
> just for our convenience.

Let's say you had the opportunity to convince a smaller independent
hosting provider that e.g. sells web hosting, e-mail and resells
internet connectivity, how would you do this? There had to be real
demand and easily installable and maintainable software to convince them
to implement STEED.

Recently I did some search and inquiries on DNSSEC, for which there is
argueably real demands from private and enterprise customers and there
is working software, but only relatively few companies worldwide offer
it and I don't expect it to be widely deployed within the next years.
However, people running their own server have it running or at leas
prepared (waiting for the registras to close the trust chain by
submitting their public key to the registry) for some time now.

> Maybe you are still not convinced. Then let me give you an illustrative
> analogy. (Disclaimer: I am not associated with SawStop or anybody involved,
> nor have I met anybody involved or used their product). An inventor created a
> table saw that can prevent injury by stopping the blade as soon as it is
> touched by human flesh ("SawStop"). According to the inventory, he could not
> get the technology to be marketed by the big table saw companies. His claim
> is that the companies think that by raising the safety measures in the table
> saw, they would be more liable for table saw accidents, which would make them
> subject to litigation. Eventually he created his own SawStop product line.
> Now, after several years, lawmakers and regulators have taken notice and might
> make sawstop like technology mandatory in table saws.
>
> Now, maybe SawStop is bad technology, maybe it's good. But at least something
> is true: As long as no candidate technology like it exists, the question
> doesn't even come up. That's the state we are at with email encryption.
> Everybody who tried has learned that email encryption is not worth the hassle.
> Everybody who hasn't tried just expects email to be secure and might not even
> be aware that it is not. It's time to change that equation, don't you think?

I agree, but there is a lot to be done. If the technical specification
is done and there is working software, there really hard work just
begins as I tried to demonstrate by taking DNSSEC as an example.

Regards,
Matthias-Christian

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


marcus.brinkmann at ruhr-uni-bochum

Oct 23, 2011, 1:56 PM

Post #58 of 80 (2748 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Hi Matthias-Christian,

thanks for your comments, I think they are entirely correct. With respect to
convincing ISPs, STEED is not a complete proposal yet. The STEED paper covers
the technical aspects of making email encryption usable for the user. It does
not cover the policies of the parties involved and strategies to break down
walls of tradition. I think there are good reasons for this. It is easier to
present the technical aspects in the form of a paper, while the policy stuff
is probably more a learning process that involves entering a dialogue of
multiple parties. Also, success of STEED may depend on external policy
changes to some extent. When those happen, we should already be in place, though.

So, you summed it up best: "there is a lot to be done"

Thanks,
Marcus

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


mwood at IUPUI

Oct 24, 2011, 8:15 AM

Post #59 of 80 (2802 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Fri, Oct 21, 2011 at 06:55:47PM +0100, MFPA wrote:
> If you are trying to get people to think about privacy, maybe
> suggesting Diaspora as an alternative to Facebook is a direction to
> consider...

I would suggest that, if you are trying to get people to think about
privacy, about the only thing worth saying to them (initially) is to
point out real-life examples of bad things happening to average people
who didn't think about privacy.

No one can desire salvation until he believes that he is in jeopardy.

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Asking whether markets are efficient is like asking whether people are smart.


rjh at sixdemonbag

Oct 24, 2011, 8:24 AM

Post #60 of 80 (2763 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/24/11 11:15 AM, Mark H. Wood wrote:
> No one can desire salvation until he believes that he is in jeopardy.

Although hellfire-and-damnation preachers are a popular cultural idea,
they're really quite rare: most preachers go more for the John 10:10
angle [*]. They've found through centuries of proselytization
experience that things work better if you pitch the benefit of the
faith, rather than the hypothesized penalties if you live without it.

The relevance here should be plain: we need to pitch the benefits of
confidential and assured communications, not the hypothetical penalties
if they fail to take our advice.



[*] "I am come that they might have life, and that they might have it
more abundantly." John 10:10, KJV
Attachments: signature.asc (0.18 KB)


mwood at IUPUI

Oct 24, 2011, 9:02 AM

Post #61 of 80 (2760 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, Oct 24, 2011 at 11:24:40AM -0400, Robert J. Hansen wrote:
> On 10/24/11 11:15 AM, Mark H. Wood wrote:
> > No one can desire salvation until he believes that he is in jeopardy.
>
> Although hellfire-and-damnation preachers are a popular cultural idea,
> they're really quite rare: most preachers go more for the John 10:10
> angle [*]. They've found through centuries of proselytization
> experience that things work better if you pitch the benefit of the
> faith, rather than the hypothesized penalties if you live without it.

And I agree with this. The problem with applying the turn-or-burn
sermon to proselytization is that it requires that the audience
already believes in sin and hell, and that the problem is one of
raising awareness. Unbelievers...don't believe. It is fortunate to
such efforts that an argument couched in terms of benefit is available.

> The relevance here should be plain: we need to pitch the benefits of
> confidential and assured communications, not the hypothetical penalties
> if they fail to take our advice.

So, in the absence of any threat, what exactly *are* those benefits?

The cited passage asserts that the hearer is missing out -- he could
have more than he has now. How much more can I get out of email by
using crypto? What do I get, if I don't believe that my privacy is
threatened or I do not value privacy?

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Asking whether markets are efficient is like asking whether people are smart.


rjh at sixdemonbag

Oct 24, 2011, 10:25 AM

Post #62 of 80 (2737 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

(There are two anecdotes here: the first is purely for amusement, the
latter is actually meant to be on-point.)

On 10/24/11 12:02 PM, Mark H. Wood wrote:
> The cited passage asserts that the hearer is missing out -- he could
> have more than he has now. How much more can I get out of email by
> using crypto? What do I get, if I don't believe that my privacy is
> threatened or I do not value privacy?

In an amusing aside, I just got back from lunch at a seafood restaurant.
While I was sitting there I encountered a street preacher who was
wandering through the tables asking people if they were saved. She (a
rare case of a woman evangelical pastor) came to my table and asked me
my opinion on homosexuality.

I blinked a few times at her. "You're asking me?" She repeated her
question. "I'm eating *shellfish* while *wearing a shirt made of two
different kinds of fabric* and you're asking me what I think of
something else that's a Levitican abomination?"

Management intervened a couple of seconds later and removed the street
preacher from the premises.

I've learned my lesson: no more citing Scripture right before lunch. :)
The strange people you meet in downtown Washington D.C...




With respect to your question: what we offer is privacy, but most people
do not understand privacy, do not care about privacy, and would not care
about privacy even if they understood it.

During graduate school the politically-active members of the Computer
Science department were up in arms over government surveillance.
Flyers, bulletin board notices, EFF fundraising campaigns, and the like.
Yet, when the Department required all TAs sign up for Facebook, in the
interests of "being accessible to the undergraduates," there wasn't any
outcry. I was serving as the Area Steward for the graduate student
labor union and tried to drum up some outrage that we were being
*required* to sign up for a privacy-annihilating 'service.' Nobody was
interested -- not even the people who had flyers on their doors
condemning Total Information Awareness and EFF stickers on their laptops.
Attachments: signature.asc (0.18 KB)


dan at geer

Oct 24, 2011, 8:02 PM

Post #63 of 80 (2752 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

>
> With respect to your question: what we offer is privacy, but most people
> do not understand privacy, do not care about privacy, and would not care
> about privacy even if they understood it.
>
> During graduate school the politically-active members of the Computer
> Science department were up in arms over government surveillance.
> Flyers, bulletin board notices, EFF fundraising campaigns, and the like.
> Yet, when the Department required all TAs sign up for Facebook, in the
> interests of "being accessible to the undergraduates," there wasn't any
> outcry. I was serving as the Area Steward for the graduate student
> labor union and tried to drum up some outrage that we were being
> *required* to sign up for a privacy-annihilating 'service.' Nobody was
> interested -- not even the people who had flyers on their doors
> condemning Total Information Awareness and EFF stickers on their laptops.
>

You got that right, Brother.

To be more pointed, how many folks on this list carry a cell phone?

--dan


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

Oct 25, 2011, 2:26 AM

Post #64 of 80 (2777 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 24/10/11 19:25, Robert J. Hansen wrote:
> With respect to your question: what we offer is privacy, but most people
> do not understand privacy, do not care about privacy, and would not care
> about privacy even if they understood it.

So if we can't motivate users by showing the bad stuff that can happen if you
have no privacy, then how to do it? I don't see any other way.

Which for a pessimist might imply that it is simply doomed, and we'll never have
e-mail crypto by default.

Though pessimists are unfortunately more often right than optimists[1], I do
think the number of TLS connections between MUAs and MTAs has increased because
the clients have it on by default. And I base this on absolutely nothing.

Peter.

PS: Nice anecdote :)


[1] Curse the researchers who actually did scientific research on this! Some
things are better left unknown and only speculated about :).

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Oct 25, 2011, 5:54 AM

Post #65 of 80 (2746 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/25/11 5:26 AM, Peter Lebbing wrote:
> So if we can't motivate users by showing the bad stuff that can
> happen if you have no privacy, then how to do it? I don't see any
> other way.

Years ago W.D. Richter wrote a fictitious interview between the two
fictitious characters Reno Nevada and Buckaroo Banzai. It sums up my
position quite well.

=====

Q: You lament the decline of the great causes -- civil rights, the
antiwar movement, the war on poverty, the exploration of space -- and
the all-consuming preoccupation with the self in today's culture. But
what gave birth to these great causes to begin with?

A: Twin utopias, unfortunately: the myth of revolution and the myth of
progress.

Q: These are myths?

A: To the extent that people believe in them as utopias, yes, which is
how they were oversold in many cases. By embracing any utopia, we sow
the seeds of cynicism when things don't work out as advertised.

Q: Not that they've ever been tried...

A: Which is the fallacy -- that big change has to happen on an
institutional or national level. When it doesn't, you have the
epidemic of cynicism we have today, with bean counters running the
whole shooting match under the rubric of being realists.

Q: So what do we failed idealists do?

A: First, stop being failures. It's absurd to judge ourselves against
a scale larger than our own efforts.

=====

I reject your premise, which seems to be that we *should* motivate
users, or that it is *possible* for us to do it. I don't think either
one is true. I don't think that I -- or any group of us -- has the
capability to do this, so my response to this is to let myself off the
hook for it.

Every now and again I'll meet someone who's interested in learning
about privacy and how to protect it. I do my best to help these
people along. That's what I can do, that's what's within my power,
that's the standard I judge myself by -- how well I do what good I can do.

It's made a world of difference in my mental health.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jeandavid8 at verizon

Oct 25, 2011, 6:12 AM

Post #66 of 80 (2758 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

dan [at] geer wrote:
>> With respect to your question: what we offer is privacy, but most
>> people do not understand privacy, do not care about privacy, and
>> would not care about privacy even if they understood it.
>>
[snip]
>
> You got that right, Brother.
>
> To be more pointed, how many folks on this list carry a cell phone?
>
> --dan
>
I carry one about half the time, but it is usually powered off unless I
am expecting a call, or when I need to make one. Also about once every
other month to use the GPS navigation feature.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 09:10:01 up 4 days, 18:16, 3 users, load average: 4.84, 5.14, 5.11

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

Oct 25, 2011, 7:57 AM

Post #67 of 80 (2731 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 25/10/11 14:54, Robert J. Hansen wrote:
> Every now and again I'll meet someone who's interested in learning
> about privacy and how to protect it. I do my best to help these
> people along. That's what I can do, that's what's within my power,
> that's the standard I judge myself by -- how well I do what good I can do.

The problem with the current proposal in that respect is that it requires
co-operation of e-mail providers. If there is no significant user base, the
providers don't want to cater for that very small minority that asks them to
implement the extra DNS functionality. And without the functionality being
offered by the e-mail providers, there is no chance to build a significant user
base.

If there was no dependency on third parties implementing stuff for their
customers, this catch-22 would not be there. It needs to be such that an
individual can say "I will install this" and then communicate with people who
did the same thing. If this individual then comes to the conclusion "My provider
does not support this", he would need to be very motivated indeed to do
something about it.

So currently there is no way to only have a few people do this, and let that
group grow slowly.

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Oct 25, 2011, 8:09 AM

Post #68 of 80 (2758 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/25/11 10:57 AM, Peter Lebbing wrote:
> The problem with the current proposal in that respect is that it
> requires co-operation of e-mail providers.

I disagree. The problem with the current proposal is it offers email
providers no payoff for their work. If it could credibly be said,
"implement STEED and you'll get 25% less spam across your network,"
email providers would be lining up around the block to participate.

As I mentioned before, most people do not understand privacy, do not see
the benefit from privacy, and even if they understood it would not see a
benefit from it. That's the dealbreaker. Hundreds of good ideas have
foundered on those shoals: I suspect STEED will turn out to be another.

But I hope I'm wrong.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg.user at seibercom

Oct 25, 2011, 8:22 AM

Post #69 of 80 (2751 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, 24 Oct 2011 23:02:32 -0400
dan [at] geer articulated:

> To be more pointed, how many folks on this list carry a cell phone?

I carry one virtually all the time. It is sort of in my job
description. I have to be available 24/7.

--
Jerry ‚úĆ
GNUPG.user [at] seibercom
_____________________________________________________________________
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

Oct 25, 2011, 11:40 AM

Post #70 of 80 (2747 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 25/10/11 17:09, Robert J. Hansen wrote:
> I disagree. The problem with the current proposal is it offers email
> providers no payoff for their work. If it could credibly be said,
> "implement STEED and you'll get 25% less spam across your network,"
> email providers would be lining up around the block to participate.

Yes, and if it could credibly be said "implement STEED and you'll get 10% more
clients", you'd need crowd control. Unfortunately, both "ifs" are not met. When
you try to create the perfect standard that solves all e-mail problems, it
quickly becomes a terrible mess. You need focus and compartmentalisation, draw
some boundaries.

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


mwood at IUPUI

Oct 25, 2011, 1:11 PM

Post #71 of 80 (2736 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

So, to summarize what I think I've been hearing: the problem which
remains to be solved (if it is a problem) is a nontechnical one, and
no amount of technical wizardry will solve it. The most that can be
done now is to be ready to help someone who fears for his privacy and
asks, "what can I do?"

Maybe someday there will be a panic and everybody will be asking.
It's good to have an answer.

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Asking whether markets are efficient is like asking whether people are smart.


rjh at sixdemonbag

Oct 25, 2011, 2:17 PM

Post #72 of 80 (2732 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/25/11 4:11 PM, Mark H. Wood wrote:
> So, to summarize what I think I've been hearing: the problem which
> remains to be solved (if it is a problem) is a nontechnical one,
> and no amount of technical wizardry will solve it.

This is what I think. But

(a) technical wizardry will be very useful for when/if
we finally figure out how to solve the social problem
(b) I might be wrong about no amount of technical wizardry
being able to solve the social problem

That's where I stand. This is why regarding STEED, I'm pessimistic but
hopeful. I doubt it will achieve the hoped-for ends: but I hope that
I'm wrong. :)

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Oct 25, 2011, 2:19 PM

Post #73 of 80 (2710 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/25/11 5:17 PM, Robert J. Hansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256

[rest of message, which *lacked* a signature, elided]

Wow, that's a wacky error. Time to file a bug report in Enigmail!

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at lists

Oct 25, 2011, 2:48 PM

Post #74 of 80 (2746 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 25/10/11 21:11, Mark H. Wood wrote:

> So, to summarize what I think I've been hearing: the problem which
> remains to be solved (if it is a problem) is a nontechnical one, and
> no amount of technical wizardry will solve it. The most that can be
> done now is to be ready to help someone who fears for his privacy and
> asks, "what can I do?"
>
> Maybe someday there will be a panic and everybody will be asking.
> It's good to have an answer.

I think there are two major technical problems which would make things a
lot easier if they were solved.

1.) A system of mapping email addresses to public keys
2.) A system of distributing private keys between all of a users email
clients automatically.

These can be tackled independently.

For #2 I'd like to see an IMAP extension where the client can upload and
download password protected private keys. The security of the keys would
rely on a strong passphrase (different from the IMAP passphrase
obviously) but it would solve the problem of copying the keys between
clients/backing them up. It would also mean that the clients can handle
the key generation/management without the user even knowing it is happening.

For #1 I'd like to see two options. First of all, the DNS solution
described in the STEED proposal. Secondly, as a backup, if the DNS
record doesn't exist, and somebody emails me with a header containing a
link (*) to their key and its fingerprint, or even just the key it's
self, I'd like to automatically use that. Initially major email
providers like GMail/Hotmail wouldn't implement the DNS solution, but
that wouldn't stop people using GMail/Hotmail with supporting IMAP
clients from automatically looking up keys and encrypting.

I can imagine these two solutions being implemented natively in Dovecot,
Courier IMAP, Evolution and Thunderbird if the right people can be
convinced. Maybe a few other widely used open source IMAP servers and
MUAs. At that point, getting noticed by Microsoft/Google/Yahoo should be
easier.

Web browsers would need to be upgraded to make functions available for
webmail providers. I'd imagine this coming later once average users are
using encrypted email without even realising. Each new implementation
would simply lead to more and more encrypted email. We don't need an all
or nothing approach.

We might even end up with MSAs that accept mail from clients without
encryption support, then look up the recipients public key, and encrypt
it before passing it on.

(*) there's a nasty privacy issue when you're able to trigger a
receiving email client to do arbitrary http lookups. It means the sender
is able to determine when the recipient downloaded the email, and what
IP address they were using at the time. Perhaps MTAs could look up the
public key on delivery and add it to the email headers.

If somebody pulls this off, the spam fighting industry is going to have
a lot of fun. It becomes a lot more difficult to identify spammy content
if you can't read it. I guess all of that filtering tech (bayes/uribl
lookups etc) would end up having to be pushed to the client. Those are
problems to be solved by other people though.

--
Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc
Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell
PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F
Attachments: signature.asc (0.44 KB)


expires2011 at ymail

Oct 25, 2011, 3:46 PM

Post #75 of 80 (2722 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Tuesday 25 October 2011 at 10:26:57 AM, in
<mid:4EA680E1.6070406 [at] digitalbrains>, Peter Lebbing wrote:


> On 24/10/11 19:25, Robert J. Hansen wrote:
>> With respect to your question: what we offer is privacy, but most people
>> do not understand privacy, do not care about privacy, and would not care
>> about privacy even if they understood it.

> So if we can't motivate users by showing the bad stuff
> that can happen if you have no privacy, then how to do
> it? I don't see any other way.

> Which for a pessimist might imply that it is simply
> doomed, and we'll never have e-mail crypto by default.

An oft-used analogy when promoting encrypted communication is to
compare it to sending a letter in an envelope rather than sending a
postcard. If people don't care about privavy, why did envelopes rather
than postcards develop as the default for sending messages through the
post?

- --
Best regards

MFPA mailto:expires2011 [at] ymail

During an eruption - move away from the volcano - not towards it
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTqc8UaipC46tDG5pAQps0gQAuGIMmK7uuyV1kxZYhk9Q3cV+BwZYIzt/
fOBOGWkFIsbAOnv815fV/adh43UOxioG0VDMxDHost2Wp+aOjVdGdNCYVYcBVUV8
+s9Or2yMIxEvjhXEbkfrEiAmB+miNjDOgpFJqdq2s6KNcYbyUQ8M/UCOcUAUaej0
LN7dErynosk=
=kSKU
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


dougb at dougbarton

Oct 25, 2011, 4:07 PM

Post #76 of 80 (1231 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/25/2011 15:46, MFPA wrote:
> An oft-used analogy when promoting encrypted communication is to compare
> it to sending a letter in an envelope rather than sending a postcard. If
> people don't care about privavy, why did envelopes rather than postcards
> develop as the default for sending messages through the post?

Privacy is certainly one reason. Others are the greater capacity of
envelopes, ability to send more than one piece of paper at a time,
ability to carry things other than paper .... I could go on. My point
being that it's just as important to observe the lenses through which we
do our observations as it is to make the observations themselves.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Oct 25, 2011, 7:02 PM

Post #77 of 80 (1221 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/25/11 6:46 PM, MFPA wrote:
> If people don't care about privavy, why did envelopes rather than
> postcards develop as the default for sending messages through the
> post?

This one should be obvious: because a postcard doesn't allow you to
write much more than a Twitter post, and many times people need to
send more than a handful of characters. In the mid-to-late '90s,
prior to the adoption of email, I was routinely sending my girlfriend
ten-page letters. The envelope was pretty handy for keeping all those
pages together.

We keep on trotting out the envelope analogy, but perhaps we should do
some more thinking before we do that. It doesn't appear to me to be
as advantageous to our position as we think. The envelope gives the
letter author immediate benefits beyond just enhanced privacy.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


lists at meumonus

Oct 26, 2011, 12:06 PM

Post #78 of 80 (1237 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

It should probably be likened to sending a letter in an security-obscured and tamper evident envelope. How often is that done?

That being said, I've appreciated the discussion on this topic. Being a neophyte to mail encryption (I haven't even set up any of my own yet) gives a good perspective of the challenge. Providing the tools, putting the security envelopes next to the regular ones, is a crucial first step and no matter how much user or carrier adoption hand-wringing occurs nothing will change until the tools are accessible.

Note the distinction between "accessible" and "available".

-Devin

-----Original Message-----
From: "Robert J. Hansen" <rjh [at] sixdemonbag>
Sender: gnupg-users-bounces [at] gnupg
Date: Tue, 25 Oct 2011 22:02:29
To: <gnupg-users [at] gnupg>
Subject: Re: STEED - Usable end-to-end encryption

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/25/11 6:46 PM, MFPA wrote:
> If people don't care about privavy, why did envelopes rather than
> postcards develop as the default for sending messages through the
> post?

This one should be obvious: because a postcard doesn't allow you to
write much more than a Twitter post, and many times people need to
send more than a handful of characters. In the mid-to-late '90s,
prior to the adoption of email, I was routinely sending my girlfriend
ten-page letters. The envelope was pretty handy for keeping all those
pages together.

We keep on trotting out the envelope analogy, but perhaps we should do
some more thinking before we do that. It doesn't appear to me to be
as advantageous to our position as we think. The envelope gives the
letter author immediate benefits beyond just enhanced privacy.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users
_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


reynt0 at cs

Nov 4, 2011, 4:05 PM

Post #79 of 80 (1189 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Oct 25, 2011, gnupg [at] lists wrote:
. . .
> (*) there's a nasty privacy issue when you're able to trigger a
> receiving email client to do arbitrary http lookups. It means the sender
> is able to determine when the recipient downloaded the email, and what
> IP address they were using at the time. Perhaps MTAs could look up the
> public key on delivery and add it to the email headers.
. . .

A comment about social psychology, FWIW:

Just from talking to ordinary users, it seems to me that a
hesitation they have is not to get involved with something
they do not much understand, particularly when the people
trying to sell it to them are telling stories about bad things
happening to people because of stuff the people do not
understand. People live their lives aware they are dependent
on a lot of stuff they can not control or really understand,
and cope by separating what is their own self and what is
"other".

Isolating the user's involvement in the system as much as
possible (eg to just locally running en/decrypt actions
including using whatever keys) might both (i) technically
protect users from bad stuff (including the bad effect
mentioned in the quote above) and (ii) make it more
comfortable for them to internalize into their own psychology
that there is this security stuff happening, because it is
OK since the experts are taking care of it for them and if
things go wrong, they (users) themselves are not to blame.
If users do not internalize the situation, they are unlikely
to want to go along with it, that is how psychology works.

Cf consider a strategy of aiming for something like technical
modularity which mimics users' psychological modularity about
the product. The system designers' problem is that they have
to look at the overall system objectively technically as well
as to take the position of the individual user and look at
the system from that point of view, too.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


kwadronaut at autistici

Mar 7, 2012, 3:14 AM

Post #80 of 80 (1058 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, 17 Oct 2011 20:11:29 +0200, Werner Koch wrote:
> of the whole system. We prepared a short paper; if you are interested

Some suggestions and questions, some are applicable to the paper while
others might be more suited for a FAQ section on the website:

* More pictures.

* You're suggesting to 'to allow easy integration with the MUA it may be
better to move the contact database into GnuPG proper.' I first read that
as duplicating functionality of, for example, existing Directory Servers.
Is that correct? If it isn't, maybe that paragraph could be clarified.

* Address the concerns some have about DNSSEC (see Micah Andersons' mail
from Fri 28 Oct 2011). Those concerns are mostly valid for TUFC if you
don't rely on more traditional mechanisms like the WOT.

* Address the size-concerns some (many?) have about publishing key
material in DNS. I know about EDNS0 and TCP, but there's a myriad of
firewalls and DNS-servers not being able to properly deal with that. IPv6
deployment is luckily (bit by bit) making more DNS-servers accessible to
answers that are >512 bytes, but it's still a challenge.

* in the conventions section you're listing GPGME as 'GnuPG Made Easy An
application library used to access the feature of GnuPG.' I'd write
features, in plural, don't be too modest ;-)

* When suggesting DNS, IPGP records seem to make most sense to me, given
the problems a lot of DNS-servers have with size. PKA and IPGP both
require some other place to actually store the key. How do you picture
solving that? Anyone has other suggestions or feedback on this?

Maybe this list has more ideas on incentives for e-mail providers for
this?

kwadronaut


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GnuPG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.