subject:"pgp signing in van"

On Sep 10, 2013, at 6:50 PM, Phillip Hallam-Baker  wrote:
> Could be but I have been working through what we know versus what would be 
> required and I really can't see how a group of people who would let Snowden 
> loose on their innermost secrets would be able to keep a conspiracy that 
> required CAs or Gmail staff or the like to participate on the scale required.

You don't need a conspiracy.   You just need to threaten the right person with 
jail.   And yes, apparently they think they can throw you in jail for quitting 
your job, if they asked you to do something for them and you quit to avoid 
doing it.   I am fairly sure that this law is unconstitutional; if you are 
independently wealthy and think you can avoid having your assets frozen, I 
encourage you to arrange to get served with an NSL and then challenge it in 
court.

Nevertheless, your optimism about this problem is not an optimism that I share, 
and apparently I am not alone in my pessimism.   You can certainly argue that 
the IETF need not address this threat model, but I don't agree with you, and 
your assurances that it's all perfectly okay are not swaying me... :)

Re: not really pgp signing in van

On Sep 10, 2013, at 5:47 PM, John R Levine  wrote:
> How likely is it that they would risk their reputation and hence their entire 
> business by screwing around with free promo S/MIME certs?

I don't know.   What happens if they are served with an NSL?   I certainly 
don't think they'd *choose* to do anything like this, but what if it's that or 
jail?   Remember, we know of at least one case of a business owner being 
threatened with jail because he closed his business rather than do precisely 
what we are discussing.

Remember too that the NSL doesn't even have to be served to the CEO—it could as 
easily be served to a geek on staff.   It's horrible to contemplate that such a 
thing might happen, but based on what we know at this point, it's not 
unreasonable to include this in our risk model.   It is _definitely_ not in the 
tin foil hat zone anymore.

Re: pgp signing in van

2013-09-10 Thread Paul Wouters


On Mon, 9 Sep 2013, Fernando Gont wrote:


It might be worth thinking about why ssh and ssl work so well, and
PGP/GPG don't.


Just a quick guess: SSL works automagically, PGP doesn't. So even if the
user doesn't care, SSL is there. PGP, OTOH, usually requires explicit
installation of a plug in and weird stuff (for mere mortals) such as
generating keys, etc.


Related (does not take away the full pain):

http://tools.ietf.org/html/draft-wouters-dane-openpgp-00

Paul

Re: not really pgp signing in van

On Sep 10, 2013, at 2:19 PM, Phillip Hallam-Baker  wrote:
> You go to a Web page that has the HTML or Javascript control for generating a 
> keypair. But the keypair is generated on the end user's computer.

So I run Javascript provided by Comodo to generate the key pair.   This means 
that my security depends on my willingness and ability to read possibly 
obfuscated Javascript to make sure that it only uploads the public half of the 
key pair.

Re: not really pgp signing in van

On Tue, Sep 10, 2013 at 2:36 PM, Ted Lemon  wrote:

> On Sep 10, 2013, at 2:19 PM, Phillip Hallam-Baker 
> wrote:
> > You go to a Web page that has the HTML or Javascript control for
> generating a keypair. But the keypair is generated on the end user's
> computer.
>
> So I run Javascript provided by Comodo to generate the key pair.   This
> means that my security depends on my willingness and ability to read
> possibly obfuscated Javascript to make sure that it only uploads the public
> half of the key pair.
>

I didn't say it was pretty. But it is subject to exactly the same potential
compromise a proprietary PGP is.

The problem is not merely that the CA might obtain the private key. A
compromised key generation mechanism could leak bits of the seed in the
modulus.

The problem is lack of transparency in key generation and that is common to
all email security programs right now.

-- 
Website: http://hallambaker.com/

Re: not really pgp signing in van

On Tue, Sep 10, 2013 at 6:06 PM, Ted Lemon  wrote:

> On Sep 10, 2013, at 5:47 PM, John R Levine  wrote:
> > How likely is it that they would risk their reputation and hence their
> entire business by screwing around with free promo S/MIME certs?
>
> I don't know.   What happens if they are served with an NSL?

Well I do not have access to the operational side of Comodo so I do not
have direct knowledge. However I have no need of the money so if I had
knowledge of an NSL that I found unconscionable then I would stop working
for them.

>   I certainly don't think they'd *choose* to do anything like this, but
> what if it's that or jail?   Remember, we know of at least one case of a
> business owner being threatened with jail because he closed his business
> rather than do precisely what we are discussing.
>

I don't think an NSL can require me to work for a company and since I am a
foreign national I am not obliged to live in the country.

Low level government functionaries rarely attempt goon tactics on people
who are relatives of cabinet ministers and have personal friends on both
front benches in parliament.

> Remember too that the NSL doesn't even have to be served to the CEO—it
> could as easily be served to a geek on staff.   It's horrible to
> contemplate that such a thing might happen, but based on what we know at
> this point, it's not unreasonable to include this in our risk model.   It
> is _definitely_ not in the tin foil hat zone anymore.
>

Could be but I have been working through what we know versus what would be
required and I really can't see how a group of people who would let Snowden
loose on their innermost secrets would be able to keep a conspiracy that
required CAs or Gmail staff or the like to participate on the scale
required.

All they would need to achieve the results as we know them from PRISM is
the knowledge of where the fiber optic cables run and a large back hoe.

-- 
Website: http://hallambaker.com/

Re: not really pgp signing in van

2013-09-10 Thread Martin Thomson

On 10 September 2013 11:36, Ted Lemon  wrote:
> So I run Javascript provided by Comodo to generate the key pair.   This means 
> that my security depends on my willingness and ability to read possibly 
> obfuscated Javascript to make sure that it only uploads the public half of 
> the key pair.

It's actually far worse than that when you consider the inherent
mutability of JavaScript.

The WebCrypto API should go a long way to addressing your concerns though.

Re: not really pgp signing in van

2013-09-10 Thread manning bill

perhaps you remember the Comodo CA fraud problem?

http://arstechnica.com/security/2011/03/how-the-comodo-certificate-fraud-calls-ca-trust-into-question/

/bill


On 10September2013Tuesday, at 14:47, John R Levine wrote:

>>> You go to a Web page that has the HTML or Javascript control for generating 
>>> a keypair. But the keypair is generated on the end user's computer.
>> 
>> So I run Javascript provided by Comodo to generate the key pair.   This 
>> means that my security depends on my willingness and ability to read 
>> possibly obfuscated Javascript to make sure that it only uploads the public 
>> half of the key pair.
> 
> I think we're entering the tinfoil zone here.  Comodo is one of the largest 
> CAs around, with their entire income depending on people paying them to sign 
> web and code certs because they are seen as trustworthy.
> 
> How likely is it that they would risk their reputation and hence their entire 
> business by screwing around with free promo S/MIME certs?
> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.

Re: not really pgp signing in van

2013-09-10 Thread Theodore Ts'o

On Tue, Sep 10, 2013 at 05:47:55PM -0400, John R Levine wrote:
> 
> I think we're entering the tinfoil zone here.  Comodo is one of the
> largest CAs around, with their entire income depending on people
> paying them to sign web and code certs because they are seen as
> trustworthy.

You might want to watch first half of Moxie Marlinspike's presentation
at Black Hat 2011, "SSL And The Future Of Authenticity".  It's not
entirely clear to me that his proposed solution is the correct one,
but his problem statement of why CA's can't be trusted to do a good
job can be found here:

http://www.youtube.com/watch?v=Z7Wl2FW2TcA

> How likely is it that they would risk their reputation and hence
> their entire business by screwing around with free promo S/MIME
> certs?

Watch the video; note that removing Comodo from the list of acceptable
CA's is really not practical, so there really is no incentive for them
to do a good job.

- Ted

Re: not really pgp signing in van

On Tue, Sep 10, 2013 at 1:18 PM, Ted Lemon  wrote:

> On Sep 10, 2013, at 12:32 PM, Phillip Hallam-Baker 
> wrote:
> > The CA NEVER ever gives the user the key in any of the systems I have
> worked on.
>
> This appears to be untrue.

> > Comodo offers that exact service today.
> >
> > https://secure.comodo.com/products/!SecureEmailCertificate_Signup
>
> The Comodo service generates the key pair for you.   This means that they
> have your private key.   We would hope that they would behave responsibly,
> but we don't have the assurance we would have if we generated the key pair
> and sent them only the public half.

You go to a Web page that has the HTML or Javascript control for generating
a keypair. But the keypair is generated on the end user's computer.

The service could send you an ActiveX keygen control with a backdoor but I
am not on Windows right now. I generated the keypair on Chrome and I have
all runtime objects turned off.

The CA returns the signed certificate to you, but that is the public key
part.

-- 
Website: http://hallambaker.com/

Re: not really pgp signing in van

On Sep 10, 2013, at 12:32 PM, Phillip Hallam-Baker  wrote:
> The CA NEVER ever gives the user the key in any of the systems I have worked 
> on.

This appears to be untrue.

> Comodo offers that exact service today.
> 
> https://secure.comodo.com/products/!SecureEmailCertificate_Signup

The Comodo service generates the key pair for you.   This means that they have 
your private key.   We would hope that they would behave responsibly, but we 
don't have the assurance we would have if we generated the key pair and sent 
them only the public half.

> Eliminate the CA and you eliminate the parties with the incentive to sell the 
> solution.

Who cares?   You can't get people to buy what they don't want.

> Whatever scheme is picked to complete secure email there is going to be a 
> problem finding end users certs and end user policies. And there may be a 
> market for solving that problem just like there is a market for blocking 
> spam. 

There is a market for it, but right now it's very small, because nobody but 
people whose activities _require_ a secure channel are interested in the 
product.

Re: not really pgp signing in van

On Mon, Sep 9, 2013 at 9:41 PM, Ted Lemon  wrote:

> On Sep 9, 2013, at 9:26 PM, John R Levine  wrote:
> > Um, didn't this start out as a discussion about how we should try to get
> > people using crypto, rather than demanding perfection that will never
> > happen?
>
> Yes.
>
> > Typical S/MIME keys are issued by CAs that verify them by
> > sending you mail with a link.  While it is easy to imagine ways that
> > could be subverted, in practice I've never seen it.
>
> The most obvious way that it can be subverted is that the CA issues you a
> key pair and gives a copy of the private key to one or more others who
> would like either to be able to pretend to be you, or to intercept
> communication that you have encrypted.   I would argue that this is
> substantially less trustworthy than a PGP key!
>

The CA NEVER ever gives the user the key in any of the systems I have
worked on.

VeriSign did offer a key recovery system for enterprise use with central
key generation but the keypair is generated on the enterprise side and
never passed to the CA.

Of course you can _do_ S/MIME with a non-shared key, but not for free, and
> not without privacy implications.   (I'm just assuming that an individual
> can get an S/MIME Cert on a self-generated public key—I haven't actually
> found a CA who offers that service.)

Comodo offers that exact service today.

https://secure.comodo.com/products/!SecureEmailCertificate_Signup

Now this product still has the usual problems of S/MIME and PGP in that
there is no infrastructure that allows a receiver to easily acquire the
certificate (except by bulk query on the CA LDAP server) and there is no
way to know what the sending policy should be.

The key pair is generated in the browser using the Javascript mechanism (as
far as I know, I have not checked but my understanding is that this is how
it works).

Just applied for a cert for Safari on ph...@hallambaker.com. Worked fine.

But the process of getting the certificate into my email client is far from
simple. Apple mail certainly has the capability to do S/MIME but the
controls to enable it are buried deep.

> > Same issue.  I can send signed mail to a buttload more people with
> > S/MIME than I can with PGP, because I have their keys in my MUA.
> > Hypothetically, one of them might be bogus.  Realistically, they aren't.
>
> Very nearly that same degree of assurance can be obtained with PGP; the
> difference is that we don't have a ready system for making it happen.
>

I don't see the value of this argument.

We have to fix key distribution. We have to make the CA actions
transparent. That means a redesign of that whole part of the technology. If
we are looking forward to new email systems then we can combine PGP Web of
Trust with S/MIME message formats.

> E.g., if my MUA grabs a copy of your key from a URL where you've published
> it, and validates email from you for a while, it could develop a degree of
> confidence in your key without requiring an external CA, and without that
> CA having a copy of your private key.   Or it could just do ssh-style
> leap-of-faith authentication of the key the first time it sees it; a fake
> key would be quickly detected unless your attacker controls your home MTA
> or the attacked identity's home MTA.

Eliminate the CA and you eliminate the parties with the incentive to sell
the solution.

Whatever scheme is picked to complete secure email there is going to be a
problem finding end users certs and end user policies. And there may be a
market for solving that problem just like there is a market for blocking
spam.

-- 
Website: http://hallambaker.com/

the evil of html was Re: pgp signing in van

2013-09-10 Thread t . p .

- Original Message -
From: "Ted Lemon" 
To: "t.p." 
Cc: "Richard Barnes" ; "Peter Saint-Andre"
; 
Sent: Tuesday, September 10, 2013 2:03 PM
On Sep 10, 2013, at 4:41 AM, t.p.  wrote:
> for reasons of
> security, of course; html has far too many attack vectors to allow it
to
> be processed in e-mail

If that's true, why is it safe for you to use HTML in a web browser?
Is it because you feel that the HTTP trust model is safer?   Are you
trying to avoid attacks via spam?   If the former, you are probably
mistaken.   If the latter, it seems to me that PGP-signed messages would
help with this, and that you ought to switch to a non-broken MUA.

Ted

A URI in a plain text e-mail means what it says; a URI in  in
html can display a perfectly innocent name while linking me to an evil
website, a much used tactic.  (If my MUA promised never to follow a
link, then I would let it process html).

With a web browser, at least I am myself choosing to click on the link,
I can easily view the underlying html if I am doubtful (possible, but
not so easy with an MUA), I can see the address in the browser address
bar and kill it if it goes where I do not want it to.  It is the user
interface of the MUA to the html that is inadequate, browsers do it
better.

But increasingly, I find web sites becoming evil, perhaps when I am
following a link from an e-mail posted to an IETF list to access
background information and then find https links being set up from my
browser to sites that I do not wish to have any truck with (e.g.
twitter, facebook), presumably in order to take clandestinely details of
me in order to build up a profile of me for some nefarious purpose.

So increasingly, I do not trust html in web sites either.

Tom Petch

Your assumption about HTML email is particularly worrisome because it is
similar to an assumption people frequently make that NATs and firewalls
keep them safe because unsolicited incoming connections are dropped.
This is of course not true, because it's not that difficult to get you
to make an outgoing connection to an address that leads to an attack
against your browser.

It's certainly easier to attack you by sending you spam, and prohibiting
HTML in email does protect you from attacks via HTML flaws by spammers.
But you pay a pretty heavy price for that protection, and it's one that
most email users would not consider paying, so by doing this you are
essentially deciding not to eat our dogfood.

If we IETFers do this sort of thing habitually, we wind up living in a
security context that most users do not live in, and wind up designing
protocols that really don't address the needs of most users.   This is
Very Bad.

Re: pgp signing in van

On Sep 10, 2013, at 4:41 AM, t.p.  wrote:
> for reasons of
> security, of course; html has far too many attack vectors to allow it to
> be processed in e-mail

If that's true, why is it safe for you to use HTML in a web browser?   Is it 
because you feel that the HTTP trust model is safer?   Are you trying to avoid 
attacks via spam?   If the former, you are probably mistaken.   If the latter, 
it seems to me that PGP-signed messages would help with this, and that you 
ought to switch to a non-broken MUA.

Your assumption about HTML email is particularly worrisome because it is 
similar to an assumption people frequently make that NATs and firewalls keep 
them safe because unsolicited incoming connections are dropped.   This is of 
course not true, because it's not that difficult to get you to make an outgoing 
connection to an address that leads to an attack against your browser.

It's certainly easier to attack you by sending you spam, and prohibiting HTML 
in email does protect you from attacks via HTML flaws by spammers.   But you 
pay a pretty heavy price for that protection, and it's one that most email 
users would not consider paying, so by doing this you are essentially deciding 
not to eat our dogfood.

If we IETFers do this sort of thing habitually, we wind up living in a security 
context that most users do not live in, and wind up designing protocols that 
really don't address the needs of most users.   This is Very Bad.

Re: not really pgp signing in van

2013-09-10 Thread Måns Nilsson

Subject: Re: not really pgp signing in van Date: Tue, Sep 10, 2013 at 
01:07:19AM - Quoting John Levine (jo...@taugh.com):
> 
> The MUAs I use (Thunderbird, Alpine, Evolution) support S/MIME a lot
> better than they support PGP.  There's typically a one key command or
> a button to turn signing and encryption on and off, and they all
> automagically import the certs from on incoming mail.


That is why you should start using mutt. Mutt fetches the PGP key that
signed a received message from key servers if it is not present in
the local keyring, and verifies it. 


As a result, I've got all the IETFers that sign messages saved in my
key ring. Automatically. Subsequent signed messages from that same sender
will either validate or be very clearly flagged as fakes. 

This is exactly the same security level that all SSH fans know
and love, ie. wide open for MITM and impostors. It is -- however --
upgradeable to "really useful" by verifying and signing the sending keys.

As has been stated before, MIME multipart signatures and their
structured data are definitely capable of maintaining the integrity
of the message one is replying to. Frequently, though, this either
means that replying properly will trash the message or deteriorate into
top-posting. Top-posting, while normally a flogging offense in my book,
has the advantage of preserving the replied-to text slightly better. The
conversation structure is OTOH trashed[0]

The one thing that comes out of this message, then, is that this is a
end-node problem that is probably best solved in MUA implementations. A
possible method could be to design a "diff" multipart -- that is a list
of edits (i'm thinking of something like "diff -e" that makes a diff as
an "ed" script that can be applied to the original message.)  applied to
the replied-to message. This multipart is then signed and transmitted,
and the receiving MUA then performs validation of the replied-to text
part, the diff part, and if they validate, will merge them, creating
a clear presentation of which lines are original and which ones are
edited. For reference, the original message of course is included and
the MUA should have a display option to show the original unaltered.

There are several problems with the above idea, for instance the notion of
ever-growing emails as all posters simply shove the history downwards to
push their stellar insights on top of the pile, but today, that is mainly
a display problem. Since I'm suggesting a fairly aggressive presentation
system with preserved history, I think that is tolerable.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
I feel like a wet parking meter on Darvon!

[0] A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


signature.asc
Description: Digital signature

Re: pgp signing in van

2013-09-10 Thread t . p .

 Original Message -
From: "Richard Barnes" 
To: "Peter Saint-Andre" 
Cc: 
Sent: Monday, September 09, 2013 6:14 PM

> It also makes it obvious to everyone that Peter is using PGP.  Which
serves
> a pedagogical function, I guess. :)

It also means I can readily view his e-mails, which may or may not be a
good thing.

With multipart/signed; micalg=pgp-sha1, on my MUA, the body of the
e-mail displays as a blank page and I have to undertake several
contortions in order to view the text, which I usually do not bother
with, relying on a later reply which is not multipart/signed which
includes the text in question which then displays as usual.

Could be worse (or better); with multipart/signed;
protocol="application/pkcs7-signature";
I get an invitation to "Continue" which doesn't, probably because I
won't allow my MUA to process html except as plain text (for reasons of
security, of course; html has far too many attack vectors to allow it to
be processed in e-mail)

Tom Petch
>
> On Mon, Sep 9, 2013 at 1:12 PM, Peter Saint-Andre
wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 9/9/13 11:02 AM, Cyrus Daboo wrote:
> > > Hi Peter,
> > >
> > > --On September 8, 2013 at 5:19:51 PM -0600 Peter Saint-Andre
> > >  wrote:
> > >
> > >>> But until the MUAs across the board support it out of the box,
> > >>> I believe most people don't know about it or know what it
> > >>> means.
> > >>
> > >> So that's an opportunity to educate people. For instance, perhaps
> > >> the Internet Society might be interested in taking on that task.
> > >
> > > Is there a reason you choose to use "inline" signing with PGP
> > > rather than multipart/signed? Is that a technical reason (e.g.,
> > > poor interoperability)?
> >
> > Ignorance or misconfiguration in my use of Thunderbird, it seems.
> >
> > Peter
> >
> > - --
> > Peter Saint-Andre
> > https://stpeter.im/
> >
> >
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> > Comment: GPGTools - http://gpgtools.org
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQIcBAEBAgAGBQJSLgF/AAoJEOoGpJErxa2pnG8P/RpJj1SDr1plL3myoumgi4iS
> > 0RLDNqq+2J+aiuDOccVJZYRITWFo3HmP3XD+nuDXiVxVUl+vuDhWHhWzQxtV04DS
> > AUTN5mgY7Z5z2wfECFzC2MmqEG9tVD7i/gTij8cHTHyFuMvF27X32nTe/gxpo0eu
> > 5cOhbzt2YWyF0nZff8cbQ+7o6d8RtaqE6G+jJVS4qUWeqEhYoFjjIGWieHZaNmw2
> > U/CQfYnAbpph/D38QDP/Tw8UJkNLXlukrbKPKtd+8Z/KAxGYkldabD01Frdkt5ZF
> > k2PosNHHpy9Ob61SH8N/vrAO/NF4c6VYEoAk8yqCgYLLNH3BSc3fSUoGjF47VU8f
> > PMKW/Hz9cG/1P5VhVTHNPx50b5Auuglo36pLIvlJjYzT8cZCpaCElhn4dScKLMLt
> > //E+/EdTs6gnayBgbok31NXPWr4ORMlaff8jSinVK08COIGyCyul+9vo2/vs4WdI
> > XZ8ToqmXUg/0d0KfRozqCQwKDHHqdkYIfTt8/rLDheXUDTTuvKWxmmLLxXs6CXMU
> > kMQ99IaRraoAVWaEiUhIdLH3Ewj7ibFsqx9UruvUX5irqDO9SbjlJC7b41iHgUIG
> > HBJiH3w947+mHLIXFJ2G9dBcv+CuOYVATqScu0jSDbsWE6xsqS1miNofyr1+al49
> > wcogO/B8kXm7cSHJjce5
> > =cGPH
> > -END PGP SIGNATURE-
> >
>

Re: not really pgp signing in van

2013-09-09 Thread Brian Trammell

On 10 Sep 2013, at 3:53, John R Levine  wrote:

>>> Typical S/MIME keys are issued by CAs that verify them by
>>> sending you mail with a link.  While it is easy to imagine ways that
>>> could be subverted, in practice I've never seen it.
>> 
>> The most obvious way that it can be subverted is that the CA issues you a 
>> key pair and gives a copy of the private key to one or more others who would 
>> like either to be able to pretend to be you, or to intercept communication 
>> that you have encrypted.   I would argue that this is substantially less 
>> trustworthy than a PGP key!
> 
> Like I said, it's easy to imagine ways it could be subverted.  If you believe 
> all CAs are crooks, you presumably don't use SSL or TLS either, right?

There's using it, and then there's trusting it to be good enough to protect 
what it's applied to protect. 

I'm reasonably certain attackers that can subvert TLS through undisclosed 
implementation vulnerabilities and/or compromised CA's aren't interested in my 
credit card number, and even if they are, the law limits my liability if I'm a 
victim of fraud -- it's priced in to the payment system. I'd estimate my risk 
is 1e-4 or so of a few hours of phone calls and paperwork, my reward is I can 
order stuff from Amazon, which is a pretty good tradeoff.

For situations where I'd actually want to encrypt email, the math is different.

> If we think that PGP is so great, how about writing native PGP support for 
> Thunderbird and Evolution, and contribute them to the open source codebase?

More important for making sure message privacy is there in the future: if we 
think that PGP is so great, let's work on native PGP support for MUAs/messaging 
apps for Android and iOS devices. We're not going to be in a situation much 
longer where the majority of the planet is using PCs for messaging, if, indeed, 
we still are.

Cheers,

Brian

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: pgp signing in van

On Sep 9, 2013, at 11:36 PM, Paul Wouters  wrote:
> Related (does not take away the full pain):

Nice.   I think section 4.2 is slightly too pessimistic, but not harmfully so.  
 It might be worth talking about leap-of-faith validation as well as 
web-of-trust validation.

Re: pgp signing in van

2013-09-09 Thread Fernando Gont

On 09/09/2013 05:17 PM, Ted Lemon wrote:
> On Sep 9, 2013, at 4:11 PM, Dan York  wrote:
>> Even in the groups where PGP was (and is) being used, usage is
>> inconsistent in part because people are now accessing their email
>> using different devices and not all of them have easy access to
>> PGP/GPG.  If you receive an encrypted message... but can only read
>> it on your laptop/desktop and not your mobile device, and you are
>> not near your laptop/desktop, how useful is the encryption if you
>> need to read the message?  You have to either wait to get back to
>> your system or ask the person to re-send unencrypted.
> 
> It might be worth thinking about why ssh and ssl work so well, and
> PGP/GPG don't.

Just a quick guess: SSL works automagically, PGP doesn't. So even if the
user doesn't care, SSL is there. PGP, OTOH, usually requires explicit
installation of a plug in and weird stuff (for mere mortals) such as
generating keys, etc.

ssh is typically use by techie people, that realize that e.g. doing
remote login is a bit crazy -- so if you're going to do remote login,
you're certainly going to use ssh (additionally, support for telnet is
disabled by default). OTOH,  how many encrypted and/or authenticated
emails does an average user sends a year?

(Not to mention the fact that at the end of the day, you can manually
check the ssh keys "once and for all" in a secure way, whereas with PGP
it's *extremely* often that people that use PGP don't get the habit of
sharing their keys in a secure way when they have the chance to -- for
instance, why doesn't everyone include their fingerprint on their
personal cards?)

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Fernando Gont

On 09/09/2013 05:48 PM, Brian E Carpenter wrote:
> On 10/09/2013 08:39, Steve Crocker wrote:
>> Yes, I am speaking of what would be possible today with a fresh start.  The 
>> fresh start would also include signatures and encryption as a required part 
>> of the design.  (If everyone has to have a key, the key management problems 
>> would be greatly reduced.)
> 
> Indeed. How one achieves such a fresh start is unclear.
> 
> (Excuse my ignorance, but do existing MUAs allow one to edit a body part
> that arrived with a PGP signature?)

Yes. That's how you can respond in-line while still signing and/or
encrypting your response.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: not really pgp signing in van

2013-09-09 Thread John R Levine


Typical S/MIME keys are issued by CAs that verify them by
sending you mail with a link.  While it is easy to imagine ways that
could be subverted, in practice I've never seen it.


The most obvious way that it can be subverted is that the CA issues you a key 
pair and gives a copy of the private key to one or more others who would like 
either to be able to pretend to be you, or to intercept communication that you 
have encrypted.   I would argue that this is substantially less trustworthy 
than a PGP key!


Like I said, it's easy to imagine ways it could be subverted.  If you 
believe all CAs are crooks, you presumably don't use SSL or TLS either, 
right?


Of course you can _do_ S/MIME with a non-shared key, but not for free, 
and not without privacy implications.  (I'm just assuming that an 
individual can get an S/MIME Cert on a self-generated public key—I 
haven't actually found a CA who offers that service.)



Same issue.  I can send signed mail to a buttload more people with
S/MIME than I can with PGP, because I have their keys in my MUA.
Hypothetically, one of them might be bogus.  Realistically, they aren't.


Very nearly that same degree of assurance can be obtained with PGP; the 
difference is that we don't have a ready system for making it happen.

E.g., if my MUA grabs a copy of your key from a URL where you've published it, 
and validates email from you for a while, it could develop a degree of 
confidence in your key without requiring an external CA, and without that CA 
having a copy of your private key.   Or it could just do ssh-style 
leap-of-faith authentication of the key the first time it sees it; a fake key 
would be quickly detected unless your attacker controls your home MTA or the 
attacked identity's home MTA.


That would be great if MUAs did that, but they don't.

As I think I've said three times now, the actual support for S/MIME in 
MUAs is a lot better than the support for PGP.  It helps that you can 
extract a correspondent's key from every S/MIME message, rather than 
having to go to a keyserver of some (likely untrustworthy) sort to get the 
PGP keys.


If we think that PGP is so great, how about writing native PGP support for 
Thunderbird and Evolution, and contribute them to the open source 
codebase?


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

smime.p7s
Description: S/MIME Cryptographic Signature

Re: not really pgp signing in van

On Sep 9, 2013, at 9:26 PM, John R Levine  wrote:
> Um, didn't this start out as a discussion about how we should try to get
> people using crypto, rather than demanding perfection that will never
> happen?

Yes.

> Typical S/MIME keys are issued by CAs that verify them by
> sending you mail with a link.  While it is easy to imagine ways that
> could be subverted, in practice I've never seen it.

The most obvious way that it can be subverted is that the CA issues you a key 
pair and gives a copy of the private key to one or more others who would like 
either to be able to pretend to be you, or to intercept communication that you 
have encrypted.   I would argue that this is substantially less trustworthy 
than a PGP key!

Of course you can _do_ S/MIME with a non-shared key, but not for free, and not 
without privacy implications.   (I'm just assuming that an individual can get 
an S/MIME Cert on a self-generated public key—I haven't actually found a CA who 
offers that service.)

> Same issue.  I can send signed mail to a buttload more people with
> S/MIME than I can with PGP, because I have their keys in my MUA.
> Hypothetically, one of them might be bogus.  Realistically, they aren't.

Very nearly that same degree of assurance can be obtained with PGP; the 
difference is that we don't have a ready system for making it happen.

E.g., if my MUA grabs a copy of your key from a URL where you've published it, 
and validates email from you for a while, it could develop a degree of 
confidence in your key without requiring an external CA, and without that CA 
having a copy of your private key.   Or it could just do ssh-style 
leap-of-faith authentication of the key the first time it sees it; a fake key 
would be quickly detected unless your attacker controls your home MTA or the 
attacked identity's home MTA.

Re: not really pgp signing in van

2013-09-09 Thread John R Levine


> Yes, and no.  PGP and S/MIME each have their own key distribution
> problems.  With PGP, it's easy to invent a key, and hard to get other
> people's software to trust it.  With S/MIME it's harder to get a key,
> but once you have one, the software is all happy.

That's a bug, not a feature.   The PGP key is almost certainly more trust=

worthy than the S/MIME key.

Um, didn't this start out as a discussion about how we should try to get
people using crypto, rather than demanding perfection that will never
happen?  Typical S/MIME keys are issued by CAs that verify them by
sending you mail with a link.  While it is easy to imagine ways that
could be subverted, in practice I've never seen it.


> The MUAs I use (Thunderbird, Alpine, Evolution) support S/MIME a lot
> better than they support PGP.  There's typically a one key command or
> a button to turn signing and encryption on and off, and they all
> automagically import the certs from on incoming mail.


Yup.  That's also a bug, not a feature.  I was just wondering why that 
is.  The only implementation I've seen a reference to is Sylpheed, which 
is not widely used


Same issue.  I can send signed mail to a buttload more people with
S/MIME than I can with PGP, because I have their keys in my MUA.
Hypothetically, one of them might be bogus.  Realistically, they aren't.

R's,
John

smime.p7s
Description: S/MIME Cryptographic Signature

Re: not really pgp signing in van

On Sep 9, 2013, at 9:07 PM, John Levine  wrote:
> Yes, and no.  PGP and S/MIME each have their own key distribution
> problems.  With PGP, it's easy to invent a key, and hard to get other
> people's software to trust it.  With S/MIME it's harder to get a key,
> but once you have one, the software is all happy.

That's a bug, not a feature.   The PGP key is almost certainly more trustworthy 
than the S/MIME key.

> The MUAs I use (Thunderbird, Alpine, Evolution) support S/MIME a lot
> better than they support PGP.  There's typically a one key command or
> a button to turn signing and encryption on and off, and they all
> automagically import the certs from on incoming mail.

Yup.   That's also a bug, not a feature.   I was just wondering why that is.   
The only implementation I've seen a reference to is Sylpheed, which is not 
widely used.

Re: What real users think [was: Re: pgp signing in van]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

>Believe it or not Ted Nelson had a similar idea when he invented Xanadu
>Hypertext. He was obsessed by copyright and the notion that it would be
>wrong to copy someone else's text to another machine, hence the need for
>links.

Well, yes, but he's never been able to implement it, despite decades
of trying.  (I've known Ted since 1972, so I watched a lot of it
happen.)  Xanadu was always envisioned as a monolithic system that
didn't scale over large numbers of machines or wide geographic areas.
It's really interesting as a conceptual design, but the closest
working implentation is the WWW and that, to put it mildly, left out a
lot.

On the other hand, MIME can do multipart messages consisting of a
sequence of signed bodies right now, and most MUAs display them pretty
well.  I've never seen anything create one other than a list manager
like Mailman or mj2 adding a signature part after a signed body.

R's,
John



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iEYEARECAAYFAlIucekACgkQkEiFRdeC/kXrfgCfYFyXhGaXoIKHiuJg1bYns/sf
6JcAn2qSoWfT/9+9LadEUbG6oHf5YvPy
=RwJq
-END PGP SIGNATURE-

Re: not really pgp signing in van

>> Sounds like we're on our way to reinventing S/MIME.  Other than the
>> key signing and distribution (which I agree is a major can of worms)
>> it works remarkably well.
>
>Which sounds kind of like, "Other than that Mrs. Lincoln, how was the play?"

Yes, and no.  PGP and S/MIME each have their own key distribution
problems.  With PGP, it's easy to invent a key, and hard to get other
people's software to trust it.  With S/MIME it's harder to get a key,
but once you have one, the software is all happy.

The MUAs I use (Thunderbird, Alpine, Evolution) support S/MIME a lot
better than they support PGP.  There's typically a one key command or
a button to turn signing and encryption on and off, and they all
automagically import the certs from on incoming mail.

R's,
John

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Phillip Hallam-Baker

On Mon, Sep 9, 2013 at 4:27 PM, Steve Crocker  wrote:

> Actually, I interpret the chemistry professor's comment in a different
> light.  It would be possible to design a system where:
>
> o the standard end user software doesn't facilitate editing the other
> person's text, and
>
> o each piece of text is signed.
>
> The result would be a system where a recipient would know whether the
> person who is alleged to have written a piece of the message actually did
> so, and the normal mode of use would be to leave things untouched.  Or, if
> you edit someone else's text, it immediately becomes your text.
>
> Steve

Believe it or not Ted Nelson had a similar idea when he invented Xanadu
Hypertext. He was obsessed by copyright and the notion that it would be
wrong to copy someone else's text to another machine, hence the need for
links.

-- 
Website: http://hallambaker.com/

Re: pgp signing in van

On Sep 9, 2013, at 5:51 PM, Arturo Servin  wrote:
>Because normally with SSL and SSH the complexity is in the server,
> not the client. When the client needs to verify the identity of some
> site with SSL we have the background browser process to check it (that
> in fact it is another weakness in the model).

The UI complexity is in the server for TLS, but not for SSH.   And indeed the 
way TLS most typically fails is that the UI in many cases fails to communicate 
the right information to the user, and fails to do what the user would need in 
order to fully protect them.

That said, it is still a very successful protocol, and delivers a lot of value 
despite its various UI issues.

Re: pgp signing in van

2013-09-09 Thread Arturo Servin

On 9/9/13 5:17 PM, Ted Lemon wrote:
> It might be worth thinking about why ssh and ssl work so well, and PGP/GPG 
> don't.

Because normally with SSL and SSH the complexity is in the server,
not the client. When the client needs to verify the identity of some
site with SSL we have the background browser process to check it (that
in fact it is another weakness in the model).

as

Re: not really pgp signing in van

>> Yes, they should have made that impossible.
>
>Oh my, I _love_ this!   This is actually the first non-covert use case I've 
>heard described,
>although I'm not convinced that PGP could actually do this without message 
>format tweaks.

Sounds like we're on our way to reinventing S/MIME.  Other than the
key signing and distribution (which I agree is a major can of worms)
it works remarkably well.

R's,
John

Re: not really pgp signing in van

On Sep 9, 2013, at 5:36 PM, John Levine  wrote:
> Sounds like we're on our way to reinventing S/MIME.  Other than the
> key signing and distribution (which I agree is a major can of worms)
> it works remarkably well.

Right.   That's the reason I don't use it.   Completely naively, may I ask why 
we never folded PGP support into S/MIME?   Or did we, and nobody implemented it?

Re: What real users think [was: Re: pgp signing in van]

On Sep 9, 2013, at 5:25 PM, Dave Crocker  wrote:
>  1.  Starting fresh means ceasing to interoperate (well) with Internet Mail.  
> We had quite a lot of exemplars of this when the Internet was starting to be 
> commercial; semantics matching was often awkward.

To be clear, what I would like to see in an MUA that addresses the use case 
Brian described is that it is just a new mime encoding that allows a message to 
be pieced together from a collection of signed attachments.   So in this 
message, the mail would be encoded as two parts. The first would be the 
complete message you wrote, with its signature.   The second would be the text 
I have written here.   The quoted text above would be represented as a 
reference to the attached message.

This should be very easy to accomplish in the UI—the UI should look exactly 
like the current UI.   It's just a tweak to how copy, cut and paste work.

There's no reason to get rid of MIME—I think it's a pretty good solution.   I 
mentioned the other solutions not because I prefer them but because they exist 
and do demonstrate that replacements for IETF standards can and do catch on in 
the marketplace, and that we ought not to just be smug about how great SMTP, 
RFC822 and MIME are and pretend that we don't have competition.

Re: What real users think [was: Re: pgp signing in van]

On Sep 9, 2013, at 5:21 PM, SM  wrote:
> Yes.  Somebody would write a MUA to do it if it wasn't possible.

What they do not, however, do, is to fix up the signature so that it still 
validates after the editing has been done.

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread John R. Levine


To be clear, what I would like to see in an MUA that addresses the use case 
Brian described is that it is just a new mime encoding that allows a message to 
be pieced together from a collection of signed attachments.   So in this 
message, the mail would be encoded as two parts. The first would be the 
complete message you wrote, with its signature.   The second would be the text 
I have written here.   The quoted text above would be represented as a 
reference to the attached message.

This should be very easy to accomplish in the UI—the UI should look exactly 
like the current UI.   It's just a tweak to how copy, cut and paste work.

There's no reason to get rid of MIME—I think it's a pretty good solution.   I 
mentioned the other solutions not because I prefer them but because they exist 
and do demonstrate that replacements for IETF standards can and do catch on in 
the marketplace, and that we ought not to just be smug about how great SMTP, 
RFC822 and MIME are and pretend that we don't have competition.


S/MIME handles this case pretty well, but I've never seen anything other 
than a list manager such as Mailman wrap signed parts together.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

smime.p7s
Description: S/MIME Cryptographic Signature

Re: not really pgp signing in van

2013-09-09 Thread Scott Kitterman

On Monday, September 09, 2013 21:36:15 John Levine wrote:
> >> Yes, they should have made that impossible.
> >
> >Oh my, I _love_ this!   This is actually the first non-covert use case I've
> >heard described, although I'm not convinced that PGP could actually do
> >this without message format tweaks.
> Sounds like we're on our way to reinventing S/MIME.  Other than the
> key signing and distribution (which I agree is a major can of worms)
> it works remarkably well.

Which sounds kind of like, "Other than that Mrs. Lincoln, how was the play?"

Scott K

Re: pgp signing in van

2013-09-09 Thread Dan York


On Sep 9, 2013, at 9:58 AM, Ted Lemon wrote:

> Seriously, this perfectly illustrates the reason why PGP hasn't seen 
> widespread deployment: it doesn't address a use case that anybody understands 
> or cares about, and it appears to address a use case that people actually 
> would like to avoid.
> 
> Here is the current use model for PGP:
> 
> (1) I generate a key and sign all my email with it
> (2) People reading my email see an obscure indicator somewhere in my email 
> that indicates that it was signed by either an unknown key (nearly always) or 
> a known key (I don't even know what that looks like)
> (3) ???
> (4) WIN!
> 
> First of all, this does nothing to preserve privacy, so I don't know why 
> we're even talking about it.   PGP in principle could be used to encrypt 
> communication, but because we don't really have an agreed-upon trust model, 
> this is a use case that only occurs when people are _highly motivated_ to 
> protect their privacy, and that's not most people, and not most of the time.
> 
> This stuff matters.   Thinking about the use model for the tools we build is 
> _the most important aspect_ of protecting peoples' privacy.   If we don't 
> think about these things, we're just producing cool toys that will never see 
> general use.

+1!  The use model is critical.  I have tried numerous times over the past many 
years to get PGP used for email (either signing or encrypting) within various 
groups but outside of small groups of more paranoid security-types it has never 
really taken off because it has been way too difficult for the average user to 
get configured and use regularly.  

Even in the groups where PGP was (and is) being used, usage is inconsistent in 
part because people are now accessing their email using different devices and 
not all of them have easy access to PGP/GPG.  If you receive an encrypted 
message... but can only read it on your laptop/desktop and not your mobile 
device, and you are not near your laptop/desktop, how useful is the encryption 
if you need to read the message?  You have to either wait to get back to your 
system or ask the person to re-send unencrypted.

For PGP to really get any real usage for email, it has to "just work" for the 
average user. 

My 2 cents,
Dan

-- 
Dan York  dy...@lodestar2.com
http://www.danyork.me/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork

Re: pgp signing in van

On Sep 9, 2013, at 5:19 PM, David Morris  wrote:
> On Mon, 9 Sep 2013, Ted Lemon wrote:
> 
>> It might be worth thinking about why ssh and ssl work so well, and PGP/GPG 
>> don't.
> 
> Umm, I question a conclusion that either ssh or ssl work well.

It's in widespread use.   Hence, it works well.   I agree that it could work 
better, but that's not what I mean by "work well."   PGP/GPG are _not_ in 
widespread use, and it is in that sense that I am suggesting that they do not 
"work well."

Maybe a better way of putting it is that they are successful protocols, in the 
RFC 5218 sense.   None of the issues you mention are protocol issues—they are 
all usability issues, and the reason they haven't been addressed is that the 
underlying mechanism works so well people do what they have to to overcome the 
usability issues.

None of which should be taken as discouragement for doing something about the 
usability issues, should you be willing to spend time on that.

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Brian E Carpenter

On 10/09/2013 08:39, Steve Crocker wrote:
> Yes, I am speaking of what would be possible today with a fresh start.  The 
> fresh start would also include signatures and encryption as a required part 
> of the design.  (If everyone has to have a key, the key management problems 
> would be greatly reduced.)

Indeed. How one achieves such a fresh start is unclear.

(Excuse my ignorance, but do existing MUAs allow one to edit a body part
that arrived with a PGP signature?)

Brian

> Steve
> 
> On Sep 9, 2013, at 4:36 PM, Dave Crocker  wrote:
> 
>> On 9/9/2013 1:27 PM, Steve Crocker wrote:
>>> Actually, I interpret the chemistry professor's comment in a
>>> different light.  It would be possible to design a system where:
>>>
>>> o the standard end user software doesn't facilitate editing the other
>>> person's text, and
>>>
>>> o each piece of text is signed.
>>>
>>> The result would be a system where a recipient would know whether the
>>> person who is alleged to have written a piece of the message actually
>>> did so, and the normal mode of use would be to leave things
>>> untouched.  Or, if you edit someone else's text, it immediately
>>> becomes your text.
>>
>> The professor's comment was on function, not method. My comment was on
>> the limitations to methods available at the time.
>>
>> In a controlled environment, with good resources, quite a bit is
>> possible. Indeed, server-based "department-level" email products in the
>> 1980s did enforce such restrictions. The single-administration servers
>> had complete control over the message.
>>
>> Distribution with independent administrative authorities makes this a
>> very different game. Enforcement by fiat is impossible.
>>
>> That's where signing comes in, of course. Modify the content and the
>> signature fails. Besides the computational overhead -- which was
>> relatively onerous back when the infrastructure was being established --
>> this requires that the receiver know and demand that the signature be
>> present; this requirement has its own adoption barriers.
>>
>> Starting with a blank sheet and today's technologies, the requirement is
>> possibly feasible to satisfy -- if we ignore the continuing human
>> factors barriers to large scale email authentication. However given the
>> resources at the time the operational service was developed, I think it
>> wasn't.
>>
>>
>> d/
>> -- 
>> Dave Crocker
>> Brandenburg InternetWorking
>> bbiw.net
> 
>

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Steve Crocker

Actually, I interpret the chemistry professor's comment in a different light.  
It would be possible to design a system where:

o the standard end user software doesn't facilitate editing the other person's 
text, and

o each piece of text is signed.

The result would be a system where a recipient would know whether the person 
who is alleged to have written a piece of the message actually did so, and the 
normal mode of use would be to leave things untouched.  Or, if you edit someone 
else's text, it immediately becomes your text.

Steve

On Sep 9, 2013, at 4:15 PM, Dave Crocker  wrote:

> On 9/9/2013 1:09 PM, Brian E Carpenter wrote:
>> I've just discovered that when
>> you forward or reply to a message, you can just change the other
>> person's text by typing over it! You'd have thought they would
>> make that impossible."
>> 
>> Yes, they should have made that impossible.
> 
> 
> Yeah, the pragmatics of truly independent, distributed processing 
> environments, with limited resources and fundamental human factors barriers 
> really are quite shocking.
> 
> d/
> 
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Dave Crocker




Indeed. How one achieves such a fresh start is unclear.


G+, Facebook, etc.   There's no shortage of fresh starts in the
personal communication space.   They just don't typically look like
typical SMTP/rfc822 email.   And of course, they substitute central
control for a distributed key model.



Let's try to avoid that line of thinking quickly:

  1.  Starting fresh means ceasing to interoperate (well) with Internet 
Mail.  We had quite a lot of exemplars of this when the Internet was 
starting to be commercial; semantics matching was often awkward.


  2.  UI differences can be important but they do not change 
interoperable semantics (or formats).  And no matter what internal 
formats a site uses, if it is to interoperate with Internet Mail with 
high resolution in the semantics, it's conforming to rfc822/2822/5322.


  3.  There are a number of features already available in email 
standards that might be relevant to this topic, but they haven't gained 
much adoption. So they were 'thought of' and even 'made possible' but 
the market chose not to pursue them.  Encapsulating a forwarded message 
in a MIME body-part is such an example; indeed, some MUAs do provide 
that option, though users typically don't take advantage of it.


d/

ps.  All of this is no doubt entertaining, but the original comment was 
about history, not about starting fresh.  My response was posted about 
that history.


pps. An example of getting the "fresh start" idea fundamentally wrong is 
with efforts to define IPv6-based email as having different semantics 
from IPv4, rather than as the transparent extension it needs to be.


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread SM


Hi Brian,
At 13:48 09-09-2013, Brian E Carpenter wrote:

(Excuse my ignorance, but do existing MUAs allow one to edit a body part
that arrived with a PGP signature?)


Yes.  Somebody would write a MUA to do it if it wasn't possible.

Regards,
-sm

Re: pgp signing in van

2013-09-09 Thread David Morris

On Mon, 9 Sep 2013, Ted Lemon wrote:

> It might be worth thinking about why ssh and ssl work so well, and PGP/GPG 
> don't.

Umm, I question a conclusion that either ssh or ssl work well. ssh works 
reasonably well around me because I can help everyone get the details
aligned. Even knowing all the rules, I frequently spend time fixing 
permission issues. Furthermore, the kinds of connectivity generally
supported is that used by techies. 

ssl works so well that I've never worked in an environment with client
certificates. (That was sarcasm, more to follow.) It works so well for me 
that it took 3 tries to get a cerficate and install it for MS Exchange 
OWA. I had a server cluster to move to a new data center. Two certificates
for two sites. My experience to that point was I had to enter a pass
phrase to get the web server to start. Turns out one certificate had
a pass phrase and one didn't, so when porting the first site didn't
result in a passphrase prompt, I conconcluded that I didn't have ssl
working OR that somehow the passphrase prompt wasn't enabled. I spent
hours and hours and didn't figure it out until I ported the second site.

I think there is a common problem for all the variations of encryption.
The tools and human interfaces are seriously lacking features needed
to make use smooth.

Code signing is another sore spot for me ... the hoops I have to
jump through to update the certificate are amazing. Confounded
last year by expiration of the root certificate.

Dave Morris

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Steve Crocker

Yes, I am speaking of what would be possible today with a fresh start.  The 
fresh start would also include signatures and encryption as a required part of 
the design.  (If everyone has to have a key, the key management problems would 
be greatly reduced.)

Steve

On Sep 9, 2013, at 4:36 PM, Dave Crocker  wrote:

> On 9/9/2013 1:27 PM, Steve Crocker wrote:
>> Actually, I interpret the chemistry professor's comment in a
>> different light.  It would be possible to design a system where:
>> 
>> o the standard end user software doesn't facilitate editing the other
>> person's text, and
>> 
>> o each piece of text is signed.
>> 
>> The result would be a system where a recipient would know whether the
>> person who is alleged to have written a piece of the message actually
>> did so, and the normal mode of use would be to leave things
>> untouched.  Or, if you edit someone else's text, it immediately
>> becomes your text.
> 
> 
> The professor's comment was on function, not method. My comment was on
> the limitations to methods available at the time.
> 
> In a controlled environment, with good resources, quite a bit is
> possible. Indeed, server-based "department-level" email products in the
> 1980s did enforce such restrictions. The single-administration servers
> had complete control over the message.
> 
> Distribution with independent administrative authorities makes this a
> very different game. Enforcement by fiat is impossible.
> 
> That's where signing comes in, of course. Modify the content and the
> signature fails. Besides the computational overhead -- which was
> relatively onerous back when the infrastructure was being established --
> this requires that the receiver know and demand that the signature be
> present; this requirement has its own adoption barriers.
> 
> Starting with a blank sheet and today's technologies, the requirement is
> possibly feasible to satisfy -- if we ignore the continuing human
> factors barriers to large scale email authentication. However given the
> resources at the time the operational service was developed, I think it
> wasn't.
> 
> 
> d/
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: What real users think [was: Re: pgp signing in van]

On Sep 9, 2013, at 4:48 PM, Brian E Carpenter  
wrote:
> Indeed. How one achieves such a fresh start is unclear.

G+, Facebook, etc.   There's no shortage of fresh starts in the personal 
communication space.   They just don't typically look like typical SMTP/rfc822 
email.   And of course, they substitute central control for a distributed key 
model.

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Hector Santos

On 9/9/2013 4:09 PM, Brian E Carpenter wrote:
> On 10/09/2013 01:58, Ted Lemon wrote:
> ...
>> Seriously, this perfectly illustrates the reason why PGP hasn't seen 
>> widespread deployment: it doesn't address a use case that anybody 
>> understands or cares about, 
> 
> True story: Last Saturday evening I was sitting waiting for a piano
> recital to start, when I overheard the person sitting behind me (who
> I happen to know is a retired chemistry professor) say to his
> companion "Email is funny, you know - I've just discovered that when
> you forward or reply to a message, you can just change the other
> person's text by typing over it! You'd have thought they would
> make that impossible."
> 
> Yes, they should have made that impossible.
> 
>Brian

Classic!

Its humiliating to think that there are tendencies to "restructure"
quoted text just to fit the common dimensions, i.e., 80x25, look
pretty -- the integrity was long gone!



-- 
HLS

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Dave Crocker


On 9/9/2013 1:27 PM, Steve Crocker wrote:

Actually, I interpret the chemistry professor's comment in a
different light.  It would be possible to design a system where:

o the standard end user software doesn't facilitate editing the other
person's text, and

o each piece of text is signed.

The result would be a system where a recipient would know whether the
person who is alleged to have written a piece of the message actually
did so, and the normal mode of use would be to leave things
untouched.  Or, if you edit someone else's text, it immediately
becomes your text.



The professor's comment was on function, not method. My comment was on
the limitations to methods available at the time.

In a controlled environment, with good resources, quite a bit is
possible. Indeed, server-based "department-level" email products in the
1980s did enforce such restrictions. The single-administration servers
had complete control over the message.

Distribution with independent administrative authorities makes this a
very different game. Enforcement by fiat is impossible.

That's where signing comes in, of course. Modify the content and the
signature fails. Besides the computational overhead -- which was
relatively onerous back when the infrastructure was being established --
this requires that the receiver know and demand that the signature be
present; this requirement has its own adoption barriers.

Starting with a blank sheet and today's technologies, the requirement is
possibly feasible to satisfy -- if we ignore the continuing human
factors barriers to large scale email authentication. However given the
resources at the time the operational service was developed, I think it
wasn't.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: What real users think [was: Re: pgp signing in van]

On Sep 9, 2013, at 4:27 PM, Steve Crocker  wrote:
> Actually, I interpret the chemistry professor's comment in a different light. 
>  It would be possible to design a system where:
> 
> o the standard end user software doesn't facilitate editing the other 
> person's text, and
> 
> o each piece of text is signed.
> 
> The result would be a system where a recipient would know whether the person 
> who is alleged to have written a piece of the message actually did so, and 
> the normal mode of use would be to leave things untouched.  Or, if you edit 
> someone else's text, it immediately becomes your text.

That's what I assumed Brian was implying, yes.   :)

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread John C Klensin

--On Tuesday, September 10, 2013 08:09 +1200 Brian E Carpenter
 wrote:

>...
> True story: Last Saturday evening I was sitting waiting for a
> piano recital to start, when I overheard the person sitting
> behind me (who I happen to know is a retired chemistry
> professor) say to his companion "Email is funny, you know -
> I've just discovered that when you forward or reply to a
> message, you can just change the other person's text by typing
> over it! You'd have thought they would make that impossible."

There is another interesting detail about this in addition to
the part of it addressed by the brothers Crocker.

When MIME was designed, there were a number of implicit
assumptions to the effect that, if an original message was
included in a reply or a message was forwarded, the original
would be a separate body part from the reply or forwarding
introduction.   Structurally, that arrangement not only would
have preserved per-body-part signatures but would have largely
avoided a number of annoyances that have caught up with us such
as an incoming message that uses different charset values than
the replying or forwarding user is set up to support.
Obviously, that would not help with replies interleaved with the
original text, but that is a somewhat different problem
(although it might take a bit of effort to explain the reasons
to your chemistry professor).  When things are interleaved,
preventing charset conflicts, modification of quoted text, and
other problems is pretty much impossible, at least, as Dave more
or less points out, if the composing MUA is under the control of
the user rather than being part of a centrally-controlled
environment that can determine what gets typed where.

It didn't work out that way.  Indeed, more than 20 years later,
forwarded messages and "reply with original included" ones are
the primary vestiges of the popular pre-MIME techniques for
marking out parts of a message.  Perhaps we should have
predicted that better, perhaps not.  But the reasons why "make
that impossible" are hard are not just security/ signature or
legacy/installed base issues.

best,
   john

Re: pgp signing in van

On Sep 9, 2013, at 4:11 PM, Dan York  wrote:
> Even in the groups where PGP was (and is) being used, usage is inconsistent 
> in part because people are now accessing their email using different devices 
> and not all of them have easy access to PGP/GPG.  If you receive an encrypted 
> message... but can only read it on your laptop/desktop and not your mobile 
> device, and you are not near your laptop/desktop, how useful is the 
> encryption if you need to read the message?  You have to either wait to get 
> back to your system or ask the person to re-send unencrypted.

It might be worth thinking about why ssh and ssl work so well, and PGP/GPG 
don't.

On Sep 9, 2013, at 4:09 PM, Brian E Carpenter  
wrote:
> True story: Last Saturday evening I was sitting waiting for a piano
> recital to start, when I overheard the person sitting behind me (who
> I happen to know is a retired chemistry professor) say to his
> companion "Email is funny, you know - I've just discovered that when
> you forward or reply to a message, you can just change the other
> person's text by typing over it! You'd have thought they would
> make that impossible."
> 
> Yes, they should have made that impossible.

Oh my, I _love_ this!   This is actually the first non-covert use case I've 
heard described, although I'm not convinced that PGP could actually do this 
without message format tweaks.

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Dave Crocker


On 9/9/2013 1:09 PM, Brian E Carpenter wrote:

 I've just discovered that when
you forward or reply to a message, you can just change the other
person's text by typing over it! You'd have thought they would
make that impossible."

Yes, they should have made that impossible.



Yeah, the pragmatics of truly independent, distributed processing 
environments, with limited resources and fundamental human factors 
barriers really are quite shocking.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: pgp signing in van

2013-09-09 Thread Anshuman Pratap Chaudhary

Chop? 

Sent from my BlackBerry® Smartphone, regret typo's!

-Original Message-
From: Ted Lemon 
Sender: ietf-boun...@ietf.org
Date: Mon, 9 Sep 2013 13:58:34 
To: IETF discussion list
Subject: Re: pgp signing in van

On Sep 9, 2013, at 8:43 AM, Michael Richardson  wrote:
>> What's the upside to signing my email?  I know why I want everybody I
>> know to sign my email, but what's the upside for me if I do it?  Until
>> there's a clear win, it's not going to happen.
> 
> It's what establishes the reputation of the key that signs your email.
> That's why having people show up to an IETF PGP signing party, when those
> people haven't been using the key is useless.   If we think that IETF
> is a meritocracy, then it doesn't matter what your government ID is.
> 
> It matters what you said on the mailing list.

On Sep 9, 2013, at 12:28 AM, l.w...@surrey.ac.uk wrote:
> There is no upside.
> 
> By signing your mail you lose plausible deniability, remove legal doubt as to 
> what you said...

Your checks are in the mail.

Seriously, this perfectly illustrates the reason why PGP hasn't seen widespread 
deployment: it doesn't address a use case that anybody understands or cares 
about, and it appears to address a use case that people actually would like to 
avoid.

Here is the current use model for PGP:

(1) I generate a key and sign all my email with it
(2) People reading my email see an obscure indicator somewhere in my email that 
indicates that it was signed by either an unknown key (nearly always) or a 
known key (I don't even know what that looks like)
(3) ???
(4) WIN!

First of all, this does nothing to preserve privacy, so I don't know why we're 
even talking about it.   PGP in principle could be used to encrypt 
communication, but because we don't really have an agreed-upon trust model, 
this is a use case that only occurs when people are _highly motivated_ to 
protect their privacy, and that's not most people, and not most of the time.

This stuff matters.   Thinking about the use model for the tools we build is 
_the most important aspect_ of protecting peoples' privacy.   If we don't think 
about these things, we're just producing cool toys that will never see general 
use.

I can actually describe a use model for PGP that accomplishes what Michael 
wants without accomplishing what Lloyd doesn't want, but let's leave that for 
another conversation.   The point I wanted to make is very simply that if we 
don't think about use models, we will never get to (4).

What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Brian E Carpenter

On 10/09/2013 01:58, Ted Lemon wrote:
...
> Seriously, this perfectly illustrates the reason why PGP hasn't seen 
> widespread deployment: it doesn't address a use case that anybody understands 
> or cares about, 

True story: Last Saturday evening I was sitting waiting for a piano
recital to start, when I overheard the person sitting behind me (who
I happen to know is a retired chemistry professor) say to his
companion "Email is funny, you know - I've just discovered that when
you forward or reply to a message, you can just change the other
person's text by typing over it! You'd have thought they would
make that impossible."

Yes, they should have made that impossible.

   Brian

Re: pgp signing in van

2013-09-09 Thread Cyrus Daboo


Hi Peter,

--On September 8, 2013 at 5:19:51 PM -0600 Peter Saint-Andre 
 wrote:



But until the MUAs across the board support it out of the box, I
believe most people don't know about it or know what it means.


So that's an opportunity to educate people. For instance, perhaps the
Internet Society might be interested in taking on that task.


Is there a reason you choose to use "inline" signing with PGP rather than 
multipart/signed? Is that a technical reason (e.g., poor interoperability)?


--
Cyrus Daboo


pgpTVGNPylnNQ.pgp
Description: PGP signature

Re: [IETF] Re: pgp signing in van

2013-09-09 Thread Warren Kumari


On Sep 9, 2013, at 1:12 PM, Peter Saint-Andre  wrote:

> Signed PGP part
> On 9/9/13 11:02 AM, Cyrus Daboo wrote:
> > Hi Peter,
> > 
> > --On September 8, 2013 at 5:19:51 PM -0600 Peter Saint-Andre 
> >  wrote:
> > 
> >>> But until the MUAs across the board support it out of the box,
> >>> I believe most people don't know about it or know what it
> >>> means.
> >> 
> >> So that's an opportunity to educate people. For instance, perhaps
> >> the Internet Society might be interested in taking on that task.
> > 
> > Is there a reason you choose to use "inline" signing with PGP
> > rather than multipart/signed? Is that a technical reason (e.g.,
> > poor interoperability)?
> 
> Ignorance or misconfiguration in my use of Thunderbird, it seems.

Or maybe you are not actually using PGP and are simply relying on 
http://xkcd.com/1181/ ?

I''ve just added:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
to my .sig file collection.

Wonder how many MUTs will become unhappy? :-P

W

> 
> Peter
> 
> - -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 

--
It must be authentic: 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://xkcd.com/1181/

W

Re: pgp signing in van

2013-09-09 Thread Scott Brim

If anyone advise me on using gmail and PGP/GPG (unicast, don't spam
the list), I'd appreciate it.  There's a plugin but it won't let me
import my keyring.

Re: pgp signing in van

2013-09-09 Thread Richard Barnes

It also makes it obvious to everyone that Peter is using PGP.  Which serves
a pedagogical function, I guess. :)


On Mon, Sep 9, 2013 at 1:12 PM, Peter Saint-Andre wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 9/9/13 11:02 AM, Cyrus Daboo wrote:
> > Hi Peter,
> >
> > --On September 8, 2013 at 5:19:51 PM -0600 Peter Saint-Andre
> >  wrote:
> >
> >>> But until the MUAs across the board support it out of the box,
> >>> I believe most people don't know about it or know what it
> >>> means.
> >>
> >> So that's an opportunity to educate people. For instance, perhaps
> >> the Internet Society might be interested in taking on that task.
> >
> > Is there a reason you choose to use "inline" signing with PGP
> > rather than multipart/signed? Is that a technical reason (e.g.,
> > poor interoperability)?
>
> Ignorance or misconfiguration in my use of Thunderbird, it seems.
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSLgF/AAoJEOoGpJErxa2pnG8P/RpJj1SDr1plL3myoumgi4iS
> 0RLDNqq+2J+aiuDOccVJZYRITWFo3HmP3XD+nuDXiVxVUl+vuDhWHhWzQxtV04DS
> AUTN5mgY7Z5z2wfECFzC2MmqEG9tVD7i/gTij8cHTHyFuMvF27X32nTe/gxpo0eu
> 5cOhbzt2YWyF0nZff8cbQ+7o6d8RtaqE6G+jJVS4qUWeqEhYoFjjIGWieHZaNmw2
> U/CQfYnAbpph/D38QDP/Tw8UJkNLXlukrbKPKtd+8Z/KAxGYkldabD01Frdkt5ZF
> k2PosNHHpy9Ob61SH8N/vrAO/NF4c6VYEoAk8yqCgYLLNH3BSc3fSUoGjF47VU8f
> PMKW/Hz9cG/1P5VhVTHNPx50b5Auuglo36pLIvlJjYzT8cZCpaCElhn4dScKLMLt
> //E+/EdTs6gnayBgbok31NXPWr4ORMlaff8jSinVK08COIGyCyul+9vo2/vs4WdI
> XZ8ToqmXUg/0d0KfRozqCQwKDHHqdkYIfTt8/rLDheXUDTTuvKWxmmLLxXs6CXMU
> kMQ99IaRraoAVWaEiUhIdLH3Ewj7ibFsqx9UruvUX5irqDO9SbjlJC7b41iHgUIG
> HBJiH3w947+mHLIXFJ2G9dBcv+CuOYVATqScu0jSDbsWE6xsqS1miNofyr1+al49
> wcogO/B8kXm7cSHJjce5
> =cGPH
> -END PGP SIGNATURE-
>

Re: pgp signing in van

2013-09-09 Thread Peter Saint-Andre

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/9/13 11:02 AM, Cyrus Daboo wrote:
> Hi Peter,
> 
> --On September 8, 2013 at 5:19:51 PM -0600 Peter Saint-Andre 
>  wrote:
> 
>>> But until the MUAs across the board support it out of the box,
>>> I believe most people don't know about it or know what it
>>> means.
>> 
>> So that's an opportunity to educate people. For instance, perhaps
>> the Internet Society might be interested in taking on that task.
> 
> Is there a reason you choose to use "inline" signing with PGP
> rather than multipart/signed? Is that a technical reason (e.g.,
> poor interoperability)?

Ignorance or misconfiguration in my use of Thunderbird, it seems.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSLgF/AAoJEOoGpJErxa2pnG8P/RpJj1SDr1plL3myoumgi4iS
0RLDNqq+2J+aiuDOccVJZYRITWFo3HmP3XD+nuDXiVxVUl+vuDhWHhWzQxtV04DS
AUTN5mgY7Z5z2wfECFzC2MmqEG9tVD7i/gTij8cHTHyFuMvF27X32nTe/gxpo0eu
5cOhbzt2YWyF0nZff8cbQ+7o6d8RtaqE6G+jJVS4qUWeqEhYoFjjIGWieHZaNmw2
U/CQfYnAbpph/D38QDP/Tw8UJkNLXlukrbKPKtd+8Z/KAxGYkldabD01Frdkt5ZF
k2PosNHHpy9Ob61SH8N/vrAO/NF4c6VYEoAk8yqCgYLLNH3BSc3fSUoGjF47VU8f
PMKW/Hz9cG/1P5VhVTHNPx50b5Auuglo36pLIvlJjYzT8cZCpaCElhn4dScKLMLt
//E+/EdTs6gnayBgbok31NXPWr4ORMlaff8jSinVK08COIGyCyul+9vo2/vs4WdI
XZ8ToqmXUg/0d0KfRozqCQwKDHHqdkYIfTt8/rLDheXUDTTuvKWxmmLLxXs6CXMU
kMQ99IaRraoAVWaEiUhIdLH3Ewj7ibFsqx9UruvUX5irqDO9SbjlJC7b41iHgUIG
HBJiH3w947+mHLIXFJ2G9dBcv+CuOYVATqScu0jSDbsWE6xsqS1miNofyr1+al49
wcogO/B8kXm7cSHJjce5
=cGPH
-END PGP SIGNATURE-

Re: pgp signing in van

On Sep 9, 2013, at 8:43 AM, Michael Richardson  wrote:
>> What's the upside to signing my email?  I know why I want everybody I
>> know to sign my email, but what's the upside for me if I do it?  Until
>> there's a clear win, it's not going to happen.
> 
> It's what establishes the reputation of the key that signs your email.
> That's why having people show up to an IETF PGP signing party, when those
> people haven't been using the key is useless.   If we think that IETF
> is a meritocracy, then it doesn't matter what your government ID is.
> 
> It matters what you said on the mailing list.

On Sep 9, 2013, at 12:28 AM, l.w...@surrey.ac.uk wrote:
> There is no upside.
> 
> By signing your mail you lose plausible deniability, remove legal doubt as to 
> what you said...

Your checks are in the mail.

Seriously, this perfectly illustrates the reason why PGP hasn't seen widespread 
deployment: it doesn't address a use case that anybody understands or cares 
about, and it appears to address a use case that people actually would like to 
avoid.

Here is the current use model for PGP:

(1) I generate a key and sign all my email with it
(2) People reading my email see an obscure indicator somewhere in my email that 
indicates that it was signed by either an unknown key (nearly always) or a 
known key (I don't even know what that looks like)
(3) ???
(4) WIN!

First of all, this does nothing to preserve privacy, so I don't know why we're 
even talking about it.   PGP in principle could be used to encrypt 
communication, but because we don't really have an agreed-upon trust model, 
this is a use case that only occurs when people are _highly motivated_ to 
protect their privacy, and that's not most people, and not most of the time.

This stuff matters.   Thinking about the use model for the tools we build is 
_the most important aspect_ of protecting peoples' privacy.   If we don't think 
about these things, we're just producing cool toys that will never see general 
use.

I can actually describe a use model for PGP that accomplishes what Michael 
wants without accomplishing what Lloyd doesn't want, but let's leave that for 
another conversation.   The point I wanted to make is very simply that if we 
don't think about use models, we will never get to (4).

Re: pgp signing in van

2013-09-09 Thread David Conrad

On Sep 9, 2013, at 1:31 AM, Brian Trammell  wrote:
> I must say at least that GPGMail (on the Mac) has gotten _much_ better in the 
> intervening decade.

+1

So far, it just works, and pretty much transparently. I've made my donation. 

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: pgp signing in van

>Why do you think that cryptographic doubt = legal doubt? I've heard
>that claim many times, but I've never heard an argument for it.

Having attempted to explain technology in court as an expert witness,
I find the assertion risible.

R's,
John

Re: pgp signing in van

2013-09-09 Thread Michael Richardson

Ted Lemon  wrote:
> On Sep 8, 2013, at 5:33 PM, Michael Richardson 

>> To all the people who posted to this thread about how they don't know
>> what a PGP key signature means, and who did not PGP or S/MIME their
>> email:

> What's the upside to signing my email?  I know why I want everybody I
> know to sign my email, but what's the upside for me if I do it?  Until
> there's a clear win, it's not going to happen.

It's what establishes the reputation of the key that signs your email.
That's why having people show up to an IETF PGP signing party, when those
people haven't been using the key is useless.   If we think that IETF
is a meritocracy, then it doesn't matter what your government ID is.

It matters what you said on the mailing list.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--
Michael Richardson , Sandelman Software Works

pgpbgW9c4TsgE.pgp
Description: PGP signature

Re: pgp signing in van

2013-09-09 Thread Peter Saint-Andre

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/8/13 10:28 PM, l.w...@surrey.ac.uk wrote:
> There is no upside.
> 
> By signing your mail you lose plausible deniability, remove legal
> doubt as to what you said...

Why do you think that cryptographic doubt = legal doubt? I've heard
that claim many times, but I've never heard an argument for it.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSLcIUAAoJEOoGpJErxa2pa5cP/3aAJ5E0GRuq2OZTniHCeVjL
2cYMAfJJnuXx/qlXnlE2sCK1w6cU1NF9nwxqN23tbs4fHBp9mEMc1ZdA0NhthCiV
zjmWur8xuPRDDuf2nCVbvvBkp/zLqksSMFpw5QS0q2SpGDNFqz1ip/4lnhuYjjdn
SwGGjPKVWHkKOnnGPOSxs0pZM+9UzhbZaHXbmY5H6EebUOhcQVqw+V+oS/TqWpSu
ZAo3e/GK8YpPkctp0XFxwED7o4gq2fPipUIhGAF0Dmpzh84EamE0ANr5NKRMIdEb
La1dzbkngxpPR5nQbNQ6+o3B3uY8p7PQMM7E4tujV/JC/XTrsRqGrkzNgYHHRlh1
04rMXPvBMR4chfjJMrfuYB84KuJg/l3ArRo0n4/4N94RsRdbXeFbip4lYazl0FmR
wUPOXqcx8Ubexp7h1BJ8InHuBP07mR18aapLmZMZC3QVa/ZFAK/dYK3A2Gdqmq9u
sB/CB2KANMUy5PPr9eROG7nD+oYTNdCIH13trYC1v4tGW8YGYxFKjn1e/cJQOq0F
pEgMUHuAqU8+NXe0HyxdI8nn0CslCgm7YTCQtBnD173E5OsTInxIpEh1Ahr9FtS4
jTlaa8Gzkt5sKU46fhs0qxLfipru1ChiWMgPxFAawuBMFQKpQIdXIsfP9f0WeDjU
kWrP+LyHyd3ydi9Zoxco
=rJSY
-END PGP SIGNATURE-

Re: pgp signing in van

2013-09-09 Thread Andrew Sullivan

On Sun, Sep 08, 2013 at 03:13:39PM -0400, John C Klensin wrote:

> On the CA side, one of the things I think is needed is a rating
> system (or collection of them on a "pick the rating service you
> trust" basis) for CAs, with an obvious extension to PGP-ish key
> signers.  In itself, that isn't a problem with which the IETF
> can help.

Well, it _was_: we had a whole working group (REPUTE) that was
established to try to provide a protocol for such rating systems.
Participation was poor.  In particular, it was very difficult to get
high quality document review.  LC just ended on most of the documents,
I note.

Best,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

Re: pgp signing in van

2013-09-09 Thread Brian Trammell

hi Hector, Peter, all,

On 9 Sep 2013, at 1:09, Hector Santos  wrote:

> 
> On 9/8/2013 6:21 PM, Peter Saint-Andre wrote:
>> On 9/8/13 3:50 PM, Ted Lemon wrote:
>>> 
>>> What's the upside to signing my email?   I know why I want
>>> everybody I know to sign my email, but what's the upside for me if
>>> I do it? Until there's a clear win, it's not going to happen.
>> 
>> There are two that I see:
>> 
>> 1. Since it's quite easy to send faked messages (and I have seen that
>> done on public lists in an effort to embarrass or impugn the sender),
>> signing one's messages makes it clear that the message really came
>> from you.
>> 
>> 2. Signing one's messages is a way of advertising that one is capable
>> of engaging in encrypted communication. (This might not be a welcome
>> analogy, but it's kind of like open carry for encryption.)
>> 
>> Peter
> 
> But until the MUAs across the board support it out of the box, I believe most 
> people don't know about it or know what it means.  See attached small snippet 
> showing the "Message Security Info" of your message according to the 
> Thunderbird MUA.
> 
> I don't think we can even establish a standard practice with PGP and others, 
> including with the recent standardized DKIM.  Where is the BCP for the MUAs, 
> MDAs, MSAs?
> 
> There will always be victims (users with MUAs) who don't support this or 
> that, but I think the IETF can finally begin considering ideal product 
> development concepts for vendors to follow.

A first step -- and a way to get over the "but nobody I communicate with 
signs/encrypts" chicken-and-egg problem -- is actually using the tools 
ourselves. In a larger sense, if we're going to talk seriously about adding 
surveillance resistance to the criteria for a "better Internet", the more of us 
use these tools, the more likely we are to make useful recommendations for 
usage and management of these technologies.

This is the reason I've started using GPG again ten years after the last use of 
my old key. I must say at least that GPGMail (on the Mac) has gotten _much_ 
better in the intervening decade.

Best regards,

Brian



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: pgp signing in van

2013-09-09 Thread Måns Nilsson

Subject: RE: pgp signing in van Date: Mon, Sep 09, 2013 at 05:28:55AM +0100 
Quoting l.w...@surrey.ac.uk (l.w...@surrey.ac.uk):
> There is no upside.
> 
> By signing your mail you lose plausible deniability, remove legal doubt as to 
> what you said...

Thinking twice about what to state has some benefits for communication. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
I'm young ... I'm HEALTHY ... I can HIKE THRU CAPT GROGAN'S LUMBAR REGIONS!


signature.asc
Description: Digital signature

RE: pgp signing in van

2013-09-08 Thread l.wood

There is no upside.

By signing your mail you lose plausible deniability, remove legal doubt as to 
what you said...

Lloyd Wood
http://sat-net.com/L.Wood/

From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Ted Lemon 
[ted.le...@nominum.com]
Sent: 08 September 2013 22:50
To: Michael Richardson
Cc: IETF discussion list
Subject: Re: pgp signing in van

On Sep 8, 2013, at 5:33 PM, Michael Richardson  wrote:
> To all the people who posted to this thread about how they don't know what
> a PGP key signature means, and who did not PGP or S/MIME their email:

What's the upside to signing my email?   I know why I want everybody I know to 
sign my email, but what's the upside for me if I do it?   Until there's a clear 
win, it's not going to happen.

Re: pgp signing in van

2013-09-08 Thread Måns Nilsson

Subject: Re: pgp signing in van Date: Sun, Sep 08, 2013 at 09:50:19PM + 
Quoting Ted Lemon (ted.le...@nominum.com):
> On Sep 8, 2013, at 5:33 PM, Michael Richardson  wrote:
> > To all the people who posted to this thread about how they don't know what
> > a PGP key signature means, and who did not PGP or S/MIME their email:
> 
> What's the upside to signing my email?   I know why I want everybody I know 
> to sign my email, but what's the upside for me if I do it?   Until there's a 
> clear win, it's not going to happen.

If you, (like I am) are persistent in signing all email, an unsigned
email from you is going to Raise Concerns.

Bonus point: Signed email gets insane upvotes in Spamassassin. 

Mutt, Mulberry, and Mail.app (the latter with GPGMail) all do a splendid
job of checking the box for you so that you mostly effortlessly can sign
all outgoing email. The software is there. The web of trust still is a
pain to maintain, but the tools and the benefits are both present. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Hey, wait a minute!!  I want a divorce!! ... you're not Clint Eastwood!!

signature.asc
Description: Digital signature

Re: pgp signing in van

2013-09-08 Thread Peter Saint-Andre

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/8/13 5:09 PM, Hector Santos wrote:
> 
> On 9/8/2013 6:21 PM, Peter Saint-Andre wrote:
>> On 9/8/13 3:50 PM, Ted Lemon wrote:
>>> 
>>> What's the upside to signing my email?   I know why I want 
>>> everybody I know to sign my email, but what's the upside for me
>>> if I do it? Until there's a clear win, it's not going to
>>> happen.
>> 
>> There are two that I see:
>> 
>> 1. Since it's quite easy to send faked messages (and I have seen
>> that done on public lists in an effort to embarrass or impugn the
>> sender), signing one's messages makes it clear that the message
>> really came from you.
>> 
>> 2. Signing one's messages is a way of advertising that one is
>> capable of engaging in encrypted communication. (This might not
>> be a welcome analogy, but it's kind of like open carry for
>> encryption.)
>> 
>> Peter
> 
> But until the MUAs across the board support it out of the box, I
> believe most people don't know about it or know what it means.

So that's an opportunity to educate people. For instance, perhaps the
Internet Society might be interested in taking on that task.

We don't need 100% of everything in order to make incremental
improvements.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSLQYXAAoJEOoGpJErxa2pm9MP/25ryFGrQXCD0oPmzXCckZq+
LgC82HQaY19vBrVfE4VPSX/6P0Ss8KxOju3pyX3AYT/JrFBu27GlSGkSPdbnBaaF
TDRWpbzw0bcqTeEFPP/OTHcgRf9ywL7W+eix2DSl/wFti8YnKlSnqxtOcRmzmlRn
Q2ddHs6khNHR34xP7B0846ffmkJPa1N/KAxI8Og/5C9amYL8xbn3U6y0rQz3+D0u
OhYgPTrTO63tbGgQI1p/3PUUgIIBVceadOQYJL6NgTXjnIf4n3/9GmKyFd+3XM8P
q/bpQz74zOMAgCC4289TSD3M6ym/j6yvL/Ji4dBNJNxDgR1d03Lx4O7RsTq1Gn4n
wduiz8hVSQv+j+hObfifQlnSEZu/FfTZAOTfryqWqPKfYSISchzot+9r3hNeIcTt
a5MsQLgIQYPsLMWFTqf9tjNYUfT0WU7g0N3ReFy94TI85E0L6EHtmOd0vrGBBad8
VFquZeZ4MfdP0Z3rQ2hgh5pRE84uNmGEpKQ9th/lBPwUurFEUgnK+vdH4MvCT3sQ
IWFG4S8l5WkGo2+BI33Pz2X4hGs/Dczhd3m7g9kWdUauHLg9iPGkpupsMWAEWK3i
BRGpIod4bBJMyuXKRNCHuD1nW/egmeGKdX3an+ClgUOekVmR2aAeUa/xZWyhExtK
Xr418Yr6rXvhVrmxb59L
=blPv
-END PGP SIGNATURE-

Re: pgp signing in van

2013-09-08 Thread Peter Saint-Andre

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/8/13 3:50 PM, Ted Lemon wrote:
> On Sep 8, 2013, at 5:33 PM, Michael Richardson 
>  wrote:
>> To all the people who posted to this thread about how they don't 
>> know what a PGP key signature means, and who did not PGP or
>> S/MIME their email:
> 
> What's the upside to signing my email?   I know why I want
> everybody I know to sign my email, but what's the upside for me if
> I do it? Until there's a clear win, it's not going to happen.

There are two that I see:

1. Since it's quite easy to send faked messages (and I have seen that
done on public lists in an effort to embarrass or impugn the sender),
signing one's messages makes it clear that the message really came
from you.

2. Signing one's messages is a way of advertising that one is capable
of engaging in encrypted communication. (This might not be a welcome
analogy, but it's kind of like open carry for encryption.)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSLPhsAAoJEOoGpJErxa2pCJgP/Rx9sytAqZEB5+4o5dUKmz2q
W54ZX0LRNPNLadAkp4tEPLyvejIK0RsQy6MEnX5rqFOF6Y8aJQqa/xxCpnXHptzZ
c3U4nBlUM/aAFurmnEWPj6fHks2tBOSEADadHp97wit/kH8Cr4SNLfqqAGi65JNf
1mmYuL9v2Ktn4e+1kUv/F2W/rPZb+g15SV2RnpFhbr2j8/TJtqm5MvoBhrtATjBP
rySxV0ERvoI2QIT6cMsl2WlZLN0w+kGFPuSaNkapIyIYc2AON258GdgjyP3Ff4mr
QXxHmuLu5BROXwYDoQzLAYrkV0To+/EzVV55lJQAWe2l1MDuC1WzJXf/92RBSuRM
xMolFrXcpdAQpqNIwXEF2p5SKNJIu8ksNAQwS9eUELB6PBhn87m+pszzKKAtT8d0
Q3jkJA96ZHvyf3dKyn76Ic7sxMJKQv7NbUnZEfZ41NyIWm3aur1kDrTXLYOx3Rf5
pL0k8dXa9RQJ96L8as4fBNGd+3bettiuy/x3PYPO8Gem2s0HZ5+ZyNnirsrJQtyx
RmHbMh6zIUWlSXKkoKi8ojy97zpJZeVKRojuF+yHQQgRK2hnAOwU4A/zach/J1JP
StrdXnRcrP+m3LtOpU1vqcj4JEky+q2Bu7EvGBYaG5I0MS5+vhcSL1zfiMPvpg9c
3zHQ34Z+10gTnbKyf+5Q
=nKdo
-END PGP SIGNATURE-

Re: pgp signing in van

2013-09-08 Thread Ted Lemon

On Sep 8, 2013, at 5:33 PM, Michael Richardson  wrote:
> To all the people who posted to this thread about how they don't know what
> a PGP key signature means, and who did not PGP or S/MIME their email:

What's the upside to signing my email?   I know why I want everybody I know to 
sign my email, but what's the upside for me if I do it?   Until there's a clear 
win, it's not going to happen.

Re: pgp signing in van

2013-09-08 Thread Michael Richardson


I have removed the attribution of this comment on purpose, because it applies
to multiple people, and I want to attack a behaviour, not a person:

>> This is what I mean by "a high bar."   Signing someone's PGP key should 
mean
>> "I know this person as X," not "this person is X."

> Dilution of trust is a problem with PGP. "I know this person as X" is way 
too
> lax if you want the system to scale.

Frankly, this is an example of pseudo-security “uphill and in the snow both
ways” that has meant that, 20 years after S/MIME and PGP, almost nobody
uses this stuff, even for the most elementary of things.

Remember: "better is the enemy of good enough".

To all the people who posted to this thread about how they don't know what
a PGP key signature means, and who did not PGP or S/MIME their email:
Stop getting in the way.
This is how an NSA mole would derail things: claim it needs to be better

--
Michael Richardson , Sandelman Software Works




pgpYzS2nrmm9x.pgp
Description: PGP signature

Re: pgp signing in van

2013-09-08 Thread Michael Richardson

Phillip Hallam-Baker  wrote:
> Could we do smime as well?

> If we had a list of smime cert fingerprints it can be used for trust
> reinforcement

Sure, but how does one establish any kind of web of trust in smime?
I have to gather everyone's certificate, and I get no transitivity.

> The issue is that smime email clients are more common so I would
> rather teach the smime doggie pgp like tricks than vice versa

I agree that they are more common, and I bemoan the fact that they aren't
used.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

Re: pgp signing in van

2013-09-08 Thread John C Klensin

--On Friday, September 06, 2013 19:50 -0800 Melinda Shore
 wrote:

> On 9/6/13 7:45 PM, Scott Kitterman wrote:
>> They have different problems, but are inherently less
>> reliable than web of  trust GPG signing.  It doesn't scale
>> well, but when done in a defined context  for defined
>> purposes it works quite well.  With external CAs you never
>> know  what you get.
> 
> Vast numbers of bits can be and have been spent on the problems
> with PKI and on vulnerabilities around CAs (and the trust
> model). I am not arguing that PKI is awesome.  What I *am*
> arguing is that the semantics of the trust assertions are
> pretty well-understood and agreed-upon, which is not the case
> with pgp.  When someone signs someone else's pgp key you
> really don't know why, what the relationship is, what they
> thought they were attesting to, etc.

I think you are both making more of a distinction than exists,
modulo the scaling problem with web of trust and something the
community has done to itself with CAs.

The web of trust scaling issue is well-known and has been
discussed repetitively.  

But the assumption about CAs has always been, more or less, that
they can all be trusted equally and that one that couldn't be
trusted would and could be held accountable.  Things just
haven't worked out that way with the net result that, as with
PGP, it is hard to deduce "why, what the relationship is, what
they thought they were attesting to", and so on.  While those
statements are in the certs or pointed to from them in many
cases, there is the immediate second-level problem of whether
those assertions can be trusted and what they mean.  For
example, if what a cert means is "passed some test for owning a
domain name", it and DANE are, as far as I can tell, identical
except for the details of the test ... and some are going to be
a lot better for some domains and registrars than others.
Assorted vendors have certainly made the situation worse by
incorporating CA root certificates in systems based on business
relationships (or worse) rather than on well-founded beliefs
about trust.

On the CA side, one of the things I think is needed is a rating
system (or collection of them on a "pick the rating service you
trust" basis) for CAs, with an obvious extension to PGP-ish key
signers.  In itself, that isn't a problem with which the IETF
can help.

Where I think the IETF and implementer communities have fallen
down is in not providing a framework that would both encourage
rating systems and tools and make them accessible to users.  In
our current environment, everything is binary in a world in
which issues like trust in a certifier is scaled and
multidimensional.   As Joe pointed out, we don't use even what
information is available in PGP levels of confidence and X.509
assertions about strength.  In the real world, we trust people
and institutions in different ways for different purposes --
I'll trust someone to work on my car, even the safety systems,
whom I wouldn't trust to do my banking... and I wouldn't want my
banker anywhere near my brakes.  In both cases, I'm probably
more interested in institutional roles and experience than I am
in whether a key (or signature on paper) binds to a hard
identity.  In some cases, binding a key to persistence is more
important than binding it to actual identity; in others, not.  I
trust my sister in most things, but wouldn't want her as a
certifier because I know she don't have sufficient clues about
managing keys.  And the amount of authentication of identity I
think I need differs with circumstances and uses too.  We
haven't designed the data structures and interfaces to make it
feasible for a casual user to incorporate judgments --her own or
those of someone she trusts -- to edit the CA lists that are
handed to her, or a PGP keyring she has constructed, and assign
conditions to them.  Nor have we specified the interface support
that would make it easy for a user to set up and get, e.g.,
warnings about low-quality certification (or keys linked to
domains or registrars that are known to be sloppy or worse) when
one is about to use them for some high-value purpose.  We have
web of trust and rating models (including PICS, which
illustrates some of difficulties with these sorts of things)
models for web pages and the like, but can't manage them for the
keys and certs that are arguably more important.

So, anyone ready to step up rather than just lamenting the state
of the world?

 best,
john

Re: pgp signing in van

2013-09-07 Thread Hector Santos

On 9/6/2013 11:04 PM, Ted Lemon wrote:

On Sep 6, 2013, at 10:35 PM, Melinda Shore wrote:

I actually don't think that pgp is likely to be particularly
useful as a "serious" trust mechanism, mostly because of
issues like this.

It's not at all clear to me that "serious" trust mechanisms should be digital
at all. Be that as it may, we have an existence proof that a web of trust is
useful�Facebook, G+ and LinkedIn all operate on a web of trust model, and it works well,
and, privacy issues aside, adds a lot of value. IETF uses an informal web of trust, and
it works well. Most open source projects use informal webs of trust, and they work
well. PGP signing for software distribution works well.

I think there is a "webs of trust" tendency to believe the negative or
the worst isn't going to happen, well, to you, until its does or at
least rears its head. There are many forms. Its a different set of
mentalities with victims. Including the worth of dealing with it when
its local vs wide spread.

The question is, can we cover the protection of them all,
communications wise, with protocols, guidelines and tools?

What these mechanisms are not is a web of trust that you could use to
authenticate a real estate transaction. You shouldn't accept them as
signatures on legal contracts. You shouldn't use them to transfer large sums
of money to strangers. But they are definitely useful.

I think the best IETF can do is to make it available for
consideration, and of course, use good engineering, and ethical,
common sense.

We have conflictive goals among many in the market place, which is now
global, and its even within market and technology leaders. The IETF
deals with communications and that should include with the end users
as well. Who are the IETF customers?

--
HLS

Re: pgp signing in van

2013-09-07 Thread Phillip Hallam-Baker

On Sat, Sep 7, 2013 at 11:29 AM, Theodore Ts'o  wrote:

> On Fri, Sep 06, 2013 at 11:39:59PM -0400, Phillip Hallam-Baker wrote:
> > For purposes of email security it is not about the keys at all. It is the
> > email addresses that are the real killer.
> >
> > I can be very sure that I have the right key for ted.lemon@nominum.combut
> > is that who I know as Ted Lemon?
>
> But if the I-D's that you are reviewing and the protocol suggestions
> are coming from ted.le...@nominum.com, does it matter?
>
> And if you subsequently then meet a bag of protoplasm at a
> face-to-face meeting who can speak in great technical detail about his
> I-D's, and who hands you a business card which says
> ted.le...@nominum.com, does it really matter what is on the
> government-issued I-D?

The difference is the ability to write a validation criteria that is
auditable. People used to get really freaked out about the fact that my
former employer accepted a CostCo membership card for ID purposes entering
the building.

The control here is accountability. If you claim to be Ted Lemon and I just
accept that then it is fairly hard to see a prosecution being viable. If on
the other hand you present a fraudulent ID then you have committed two
separate acts of fraud (one obtaining, second presenting). There are
criminal sanctions possible.

> > One value of IETF key signing parties is that we get a better assurance
> > that we know the email address we are sending to is the address of the
> Ted
> > Lemon that participates in IETF than we can possibly get through Web of
> > Trust where someone may be signing a key in all good faith but for the
> > wrong person.
>
> Exactly.  This is basically how we bootstrapped the GPG keyring used
> for Linux kernel submissions after the kernel.org security breech two
> years ago.  We required everyone to get new GPG keys, thus forcing a
> key rotation, and we did in-person key verification of people, most of
> whom we had met at other Linux conferences previously, so we knew who
> we were dealing with.
>

Which is exactly the type of community where PGP works well. The problem is
that you can't scale to populations of a billion or more by holding key
signing parties.

> We did look at each other's government-issued ID's, but honestly, that
> was much less important than my being able to say, something like,
> "Why yes, that's James Bottomley, the SCSI maintainer and someone with
> whom I've worked with for the past decade, on mailing lists and
> conference calls and at conferences all over the world."
>

Government issued IDs do have one big advantage and that is they allow new
people to introduce themselves into the group. They also provide a control
against long term undercover agents.

Police don't usually have access to forged documents when they go
undercover. Even intelligence agencies are forced to use them sparingly as
maintaining them is high cost.

> For this reason, it's actually better to do mini-key signings (or
> really, exchange of GPG key fingerprints) at the end of each working
> group session, rather than trying to do one big key signing one
> evening.  The latter is more time-efficient, but the former is what's
> actually important, since it will be the working group members who
> know each other the best.
>

You want me to give up my coffee and biscuits?

> The other thing which is useful for a community to maintain is a
> centralized keyring of all of the members, backed up on a time stamped
> WORM drive, where keys only get added to the keyring after it has been
> signed by a threshold number of trusted core signers.  (Initially, for
> kernel.org there were only four or five us that were core trusted
> signers, and we were people who knew each other and had been working
> on the Linux kernel for a long time.)
>

Oddly enough that is similar to the proposal I have been looking at and Ben
Laurie has. Only instead of hardware we are looking at catenate
certificates (Harber & Stornetta hash chains) now the patent is expired.

> Of course, all of this is not going to solve the problem of someone
> getting bribed by some state actor to introduce some vulnerability
> into a codebase, or into some IETF- or NIST- approved
> standards/protocol document.  After all, government ID's don't come
> with a stamp, "I am an NSA stooge."  :-)
>

And some folk may well have been unwitting stooges.

-- 
Website: http://hallambaker.com/

Re: pgp signing in van

2013-09-07 Thread Hector Santos


On 9/6/2013 10:35 PM, Melinda Shore wrote:


One of the useful things that PKI provides is some agreement,
at least, about what we expect from certification authorities
and what it means to issue and sign a certificate.  That is
to say, the semantics are reasonably well sorted-out, which is
not the case with pgp.

Melinda



Much of the discussions also deals with how protocol implementators, 
i.e., mail, browser, routers market, has added these as features.  Are 
they secured out of the box?


For example, the browser market has recently began to enable OCSP 
(Online Certificate Status Protocol) out of the box. Is this good or 
bad?  Is this further violation of privacy? an ethical concern.  Is it 
more 3rd party tracking, monitoring with a good security purpose?


Add the same concept to the address bar searching methodologies that 
are now also enabling the out of the box for further 3rd party search 
and tracking path.


Add to that Javascript, 3rd party cookies and cross domain 
communications, once a major taboo, is now enabled out of the box. 
The enabling of "ping home" and "cross talking" ideas across the 
board, it is all enabled now.


Overall, we lost the focus of private by design with this exploding 
need to socialize and share information mentality.  Its not end to end 
any more.  Its an OPT-OUT, not OPT-IN mentality. The market is 
allowing it to happen, is it because they are aware of this and a made 
a choice or they don't even know it was even an issue?


The IETF methodology needs to be revamped to lead the way ago, take 
more charge of not being so relaxed in its security aspects towards 
communications protocols.  Consolidation of information is a start.


We knew since the beginning of SMTP how it was well known the SMTP 
(821) sender/return path was not secured.  Too much spoofing 
potential, yet it was written in stone in RFC2821 not to hurt a useful 
feature because of an ignorant bad guy.  Well, we finally recognized 
the bad guy was no longer ignorant by RFC5321. It took nearly a score 
of years to begin to address it, we have SPF for example, we have DKIM 
too.


And even then, we are still too relaxed.  I have always called for 
strong exclusive end to end, i.e., SPF -ALL, policies when possible. 
ADSP for DKIM, etc.


But overall, we allowed too much security relaxation into the 
protocols, making it them work with much lower payoffs and much more 
waste on the system.  We passed the buck to others and the future to 
address these well known issues. Too much time wasted.


The IETF can do better to lead the way.

--
HLS

Re: pgp signing in van

2013-09-07 Thread Theodore Ts'o

On Fri, Sep 06, 2013 at 11:39:59PM -0400, Phillip Hallam-Baker wrote:
> For purposes of email security it is not about the keys at all. It is the
> email addresses that are the real killer.
> 
> I can be very sure that I have the right key for ted.le...@nominum.com but
> is that who I know as Ted Lemon?

But if the I-D's that you are reviewing and the protocol suggestions
are coming from ted.le...@nominum.com, does it matter?

And if you subsequently then meet a bag of protoplasm at a
face-to-face meeting who can speak in great technical detail about his
I-D's, and who hands you a business card which says
ted.le...@nominum.com, does it really matter what is on the
government-issued I-D?

> One value of IETF key signing parties is that we get a better assurance
> that we know the email address we are sending to is the address of the Ted
> Lemon that participates in IETF than we can possibly get through Web of
> Trust where someone may be signing a key in all good faith but for the
> wrong person.

Exactly.  This is basically how we bootstrapped the GPG keyring used
for Linux kernel submissions after the kernel.org security breech two
years ago.  We required everyone to get new GPG keys, thus forcing a
key rotation, and we did in-person key verification of people, most of
whom we had met at other Linux conferences previously, so we knew who
we were dealing with.

We did look at each other's government-issued ID's, but honestly, that
was much less important than my being able to say, something like,
"Why yes, that's James Bottomley, the SCSI maintainer and someone with
whom I've worked with for the past decade, on mailing lists and
conference calls and at conferences all over the world."

For this reason, it's actually better to do mini-key signings (or
really, exchange of GPG key fingerprints) at the end of each working
group session, rather than trying to do one big key signing one
evening.  The latter is more time-efficient, but the former is what's
actually important, since it will be the working group members who
know each other the best.

The other thing which is useful for a community to maintain is a
centralized keyring of all of the members, backed up on a time stamped
WORM drive, where keys only get added to the keyring after it has been
signed by a threshold number of trusted core signers.  (Initially, for
kernel.org there were only four or five us that were core trusted
signers, and we were people who knew each other and had been working
on the Linux kernel for a long time.)

Of course, all of this is not going to solve the problem of someone
getting bribed by some state actor to introduce some vulnerability
into a codebase, or into some IETF- or NIST- approved
standards/protocol document.  After all, government ID's don't come
with a stamp, "I am an NSA stooge."  :-)

- Ted

Re: pgp signing in van

2013-09-07 Thread Pete Resnick


On 9/6/13 6:33 PM, Phillip Hallam-Baker wrote:
Almost everyone arriving in Vancouver will have a passport in any 
case. The protocol will probably be something like provide your key 
etc data in advance, print something out and present that plus your ID 
document in the ceremony.



You mean you want me to trust that you have seen an ID issued by, for 
example, the US Government (of recent infamy on this list) that 
indicates that a particular name goes with the person pictured and that 
that person uses a particular certificate? And that is supposed to be 
helpful to me how?



I've really never understood this model of trust. Unless you can convey 
to me what kinds of things you sign and on what basis, I can't assign 
any value to your assurances. Joe Touch's recent comment seems right: 
"as long as endorsements are equal, they're only as good as your weakest 
one."


(And no, I don't have greater faith in CA-based certs. Just because 
there are currently only two choices doesn't mean I have to like either 
one.)


pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

Re: pgp signing in van

On Friday, September 06, 2013 19:50:28 Melinda Shore wrote:
> On 9/6/13 7:45 PM, Scott Kitterman wrote:
> > They have different problems, but are inherently less reliable than web of
> > trust GPG signing.  It doesn't scale well, but when done in a defined
> > context for defined purposes it works quite well.  With external CAs you
> > never know what you get.
> 
> Vast numbers of bits can be and have been spent on the problems
> with PKI and on vulnerabilities around CAs (and the trust model).
> I am not arguing that PKI is awesome.  What I *am* arguing is that
> the semantics of the trust assertions are pretty well-understood
> and agreed-upon, which is not the case with pgp.  When someone
> signs someone else's pgp key you really don't know why, what the
> relationship is, what they thought they were attesting to, etc.

If you think CA assertions are any better, then I beg to differ.  Just for fun:

http://www.winrumors.com/microsoft-warns-of-fake-ssl-certificates-issued-for-gmail-yahoo-skype-and-others/

Scott K

Re: pgp signing in van

On 9/6/13 7:45 PM, Scott Kitterman wrote:
> They have different problems, but are inherently less reliable than web of 
> trust GPG signing.  It doesn't scale well, but when done in a defined context 
> for defined purposes it works quite well.  With external CAs you never know 
> what you get.

Vast numbers of bits can be and have been spent on the problems
with PKI and on vulnerabilities around CAs (and the trust model).
I am not arguing that PKI is awesome.  What I *am* arguing is that
the semantics of the trust assertions are pretty well-understood
and agreed-upon, which is not the case with pgp.  When someone
signs someone else's pgp key you really don't know why, what the
relationship is, what they thought they were attesting to, etc.

Melinda

Re: pgp signing in van

On Friday, September 06, 2013 23:39:59 Phillip Hallam-Baker wrote:
> On Fri, Sep 6, 2013 at 9:09 PM, Ted Lemon  wrote:
> > On Sep 6, 2013, at 8:21 PM, Melinda Shore  wrote:
> > > when you vouch for someone's identity - in an authoritative
> > > trust system - you're also vouching for the authenticity of
> > > their transactions.
> > 
> > This is what I mean by "a high bar."   Signing someone's PGP key should
> > mean "I know this person as X," not "this person is X."
> 
> For purposes of email security it is not about the keys at all. It is the
> email addresses that are the real killer.
> 
> I can be very sure that I have the right key for ted.le...@nominum.com but
> is that who I know as Ted Lemon?
> 
> 
> One value of IETF key signing parties is that we get a better assurance
> that we know the email address we are sending to is the address of the Ted
> Lemon that participates in IETF than we can possibly get through Web of
> Trust where someone may be signing a key in all good faith but for the
> wrong person.

Except what you're talking about is building an IETF centered web of trust.  
That's exactly the right thing to be doing.  For all the key singings I've 
done the signer mails the signed key to the signee to upload to a key server.  
That does provide reasonable assurance that the key, the person, and the email 
address go together.

Scott K

Re: pgp signing in van

On Friday, September 06, 2013 19:12:58 Melinda Shore wrote:
> On 9/6/13 7:04 PM, Ted Lemon wrote:
> > It's not at all clear to me that "serious" trust mechanisms should be
> > digital at all.
> 
> They're not.
> 
> > Be that as it may, we have an existence proof that
> > a web of trust is useful—Facebook, G+ and LinkedIn all operate on a
> > web of trust model, and it works well, and, privacy issues aside,
> > adds a lot of value.
> 
> I'm not quite sure how we got from the question of how to
> do crypto better as a means to provide stronger privacy
> protections to the value of Facebook, to be honest.
> Possibly because of the key signing proposal.
> 
> But here's some anecdata.  Got a FB friend request from
> someone I didn't know, checked him out and we seemed to have
> quite a few friends in common, so I accepted.  When he did,
> in fact, turn out to be a jerk I wrote to some of the
> friends-in-common and it turns out that nobody knew who he
> was - a few people with lax friending policies had accepted
> his friend requests and that formed the basis for a bunch of
> the rest of us assuming he'd be okay.
> 
> At any rate I think it's pretty clear that the semantics
> of pgp signing are not agreed-upon and that's led to a
> lack of clarity around individual decisions about key signing.
> I find pgp useful for sloppy, casual, but easy-to-use crypto
> but I certainly wouldn't want to use it as the basis for
> assurances about identity, etc.

Because you trust PKI CAs so much more?

They have different problems, but are inherently less reliable than web of 
trust GPG signing.  It doesn't scale well, but when done in a defined context 
for defined purposes it works quite well.  With external CAs you never know 
what you get.

Scott K

Re: pgp signing in van

2013-09-06 Thread Phillip Hallam-Baker

On Fri, Sep 6, 2013 at 9:09 PM, Ted Lemon  wrote:

> On Sep 6, 2013, at 8:21 PM, Melinda Shore  wrote:
> > when you vouch for someone's identity - in an authoritative
> > trust system - you're also vouching for the authenticity of
> > their transactions.
>
> This is what I mean by "a high bar."   Signing someone's PGP key should
> mean "I know this person as X," not "this person is X."
>
>
For purposes of email security it is not about the keys at all. It is the
email addresses that are the real killer.

I can be very sure that I have the right key for ted.le...@nominum.com but
is that who I know as Ted Lemon?

One value of IETF key signing parties is that we get a better assurance
that we know the email address we are sending to is the address of the Ted
Lemon that participates in IETF than we can possibly get through Web of
Trust where someone may be signing a key in all good faith but for the
wrong person.

-- 
Website: http://hallambaker.com/

Re: pgp signing in van

On Sep 6, 2013, at 11:12 PM, Melinda Shore  wrote:
> I'm not quite sure how we got from the question of how to
> do crypto better as a means to provide stronger privacy
> protections to the value of Facebook, to be honest.
> Possibly because of the key signing proposal.

It's not an accident.   IMHO PGP is friending done right, in the sense that 
only you and your friend need know you friended each other.   There's no 
central service provider who knows who's friends with whom, for all values of 
whom.

> But here's some anecdata.  Got a FB friend request from
> someone I didn't know, checked him out and we seemed to have
> quite a few friends in common, so I accepted.  When he did,
> in fact, turn out to be a jerk I wrote to some of the
> friends-in-common and it turns out that nobody knew who he
> was - a few people with lax friending policies had accepted
> his friend requests and that formed the basis for a bunch of
> the rest of us assuming he'd be okay.

Don't blame your friends.   I never friend anyone I don't know personally.  Our 
different styles illustrate the problem rather nicely... :)

> At any rate I think it's pretty clear that the semantics
> of pgp signing are not agreed-upon and that's led to a
> lack of clarity around individual decisions about key signing.
> I find pgp useful for sloppy, casual, but easy-to-use crypto
> but I certainly wouldn't want to use it as the basis for
> assurances about identity, etc.

Yes.   But it is still _very_ useful.

Re: pgp signing in van

On 9/6/13 7:04 PM, Ted Lemon wrote:
> It's not at all clear to me that "serious" trust mechanisms should be
> digital at all.   

They're not.

> Be that as it may, we have an existence proof that
> a web of trust is useful—Facebook, G+ and LinkedIn all operate on a
> web of trust model, and it works well, and, privacy issues aside,
> adds a lot of value.  

I'm not quite sure how we got from the question of how to
do crypto better as a means to provide stronger privacy
protections to the value of Facebook, to be honest.
Possibly because of the key signing proposal.

But here's some anecdata.  Got a FB friend request from
someone I didn't know, checked him out and we seemed to have
quite a few friends in common, so I accepted.  When he did,
in fact, turn out to be a jerk I wrote to some of the
friends-in-common and it turns out that nobody knew who he
was - a few people with lax friending policies had accepted
his friend requests and that formed the basis for a bunch of
the rest of us assuming he'd be okay.

At any rate I think it's pretty clear that the semantics
of pgp signing are not agreed-upon and that's led to a
lack of clarity around individual decisions about key signing.
I find pgp useful for sloppy, casual, but easy-to-use crypto
but I certainly wouldn't want to use it as the basis for
assurances about identity, etc.

Melinda

Re: pgp signing in van

On Sep 6, 2013, at 10:35 PM, Melinda Shore  wrote:
> I actually don't think that pgp is likely to be particularly
> useful as a "serious" trust mechanism, mostly because of
> issues like this.

It's not at all clear to me that "serious" trust mechanisms should be digital 
at all.   Be that as it may, we have an existence proof that a web of trust is 
useful—Facebook, G+ and LinkedIn all operate on a web of trust model, and it 
works well, and, privacy issues aside, adds a lot of value.   IETF uses an 
informal web of trust, and it works well.   Most open source projects use 
informal webs of trust, and they work well.   PGP signing for software 
distribution works well.

What these mechanisms are not is a web of trust that you could use to 
authenticate a real estate transaction.   You shouldn't accept them as 
signatures on legal contracts.   You shouldn't use them to transfer large sums 
of money to strangers.   But they are definitely useful.

Re: pgp signing in van

On 9/6/13 6:24 PM, Ted Lemon wrote:
> It's naive to think that keys are any more trustworthy than this,
> because any signature's trustworthiness is only as good as the
> trustworthiness of the individual who decides to sign it.   If you
> trust a key signed by someone you don't know, but who someone you
> know trusts, just how trustworthy is that?

I actually don't think that pgp is likely to be particularly
useful as a "serious" trust mechanism, mostly because of
issues like this.  I don't believe that it's an argument for
less rigor in how we assign trust to signatures but rather
an example of several underlying problems, including lack
of agreement about what it actually means to sign something,
acknowledgment that you don't know much about how the
people whose keys you're signing think about trust ("My friends
are fine but some of their friends are jerks"), etc.

One of the useful things that PKI provides is some agreement,
at least, about what we expect from certification authorities
and what it means to issue and sign a certificate.  That is
to say, the semantics are reasonably well sorted-out, which is
not the case with pgp.

Melinda

Re: pgp signing in van

On Sep 6, 2013, at 10:18 PM, Scott Brim  wrote:
> Dilution of trust is a problem with PGP. "I know this person as X" is way too 
> lax if you want the system to scale.

It's naive to think that keys are any more trustworthy than this, because any 
signature's trustworthiness is only as good as the trustworthiness of the 
individual who decides to sign it.   If you trust a key signed by someone you 
don't know, but who someone you know trusts, just how trustworthy is that?

The web of trust scales just fine if you don't expect too much from it.   If 
you expect the kind of trustworthiness you seem to be talking about, then it's 
pretty much useless, because you can really only trust yourself to that degree.

I don't know if this is the sort of absolutism Ted Ts'o was talking about, but 
I think it is.   Sometimes best is the enemy of good enough, and this is 
particularly true when best is actually not achievable anyway.

Re: pgp signing in van

2013-09-06 Thread Scott Brim

On Sep 6, 2013 9:10 PM, "Ted Lemon"  wrote:
>
> On Sep 6, 2013, at 8:21 PM, Melinda Shore  wrote:
> > when you vouch for someone's identity - in an authoritative
> > trust system - you're also vouching for the authenticity of
> > their transactions.
>
> This is what I mean by "a high bar."   Signing someone's PGP key should
mean "I know this person as X," not "this person is X."
>

Dilution of trust is a problem with PGP. "I know this person as X" is way
too lax if you want the system to scale.

Scott

Re: pgp signing in van

On Sep 6, 2013, at 9:24 PM, Melinda Shore  wrote:
> I'm not sure why
> "I know this person as " provides much more reliability
> than someone asserting their own identity.

Actually it's quite useful.   It allows me to differentiate email coming from 
someone I know as X from email coming from someone claiming to be that person, 
but who does not possess their key.

Re: pgp signing in van



Phillip Hallam-Baker  wrote:
>On Fri, Sep 6, 2013 at 6:42 PM, Joe Touch  wrote:
>
>>
>>
>> On 9/6/2013 10:17 AM, Michael Richardson wrote:
>>
>>>
>>> I will be happy to participate in a pgp signing party.
>>> Organized or not.
>>>
>>> I suggest that an appropriate venue is during the last 15 minutes of
>the
>>> newcomer welcome and the first 15 minutes of the welcome reception.
>>>
>>> Because:
>>>1) the WG-chairs and IESG will all be there, and a web of trust
>>>   still needs some significant good connectivity, and we already
>>>   know each other rather well, without needing "ID"
>>>   (I am not interested myself in verifying anyone's
>NSA^WGovernment
>>>   identity. I don't trust that Certification Authority...)
>>>
>>>2) getting newbies on-board, meeting them well enough to sign
>>>   their key seems like a good thing.
>>>
>>
>> And whose key would you sign? Anyone who showed up with a form of ID?
>>
>> I've noted elsewhere that the current typical key-signing party
>methods
>> are very weak. You should sign only the keys of those who you know
>well
>> enough to claim you can attest to their identity.
>>
>> If that's the case, how will this get newbies on-board except to
>invite
>> them to have keys whose signatures aren't relevant, and to devalue
>the
>> trust in WG-chairs and IESG members?
>>
>> Joe
>>
>
>I can write a key ceremony spec. I have done that before.
>
>Almost everyone arriving in Vancouver will have a passport in any case.
>The
>protocol will probably be something like provide your key etc data in
>advance, print something out and present that plus your ID document in
>the
>ceremony.

Here's one approach that works reasonably well:


http://www.debian.org/events/keysigning

The scripts in the mentioned signing party package make things much easier. 

Scott K

Re: pgp signing in van

2013-09-06 Thread Joe Touch




On 9/6/2013 5:10 PM, Ted Lemon wrote:

On Sep 6, 2013, at 6:42 PM, Joe Touch  wrote:

I've noted elsewhere that the current typical key-signing party
methods are very weak. You should sign only the keys of those who you
know well enough to claim you can attest to their identity.


This is a ridiculously high bar.   The bar should be about at the
level of a facebook friend request.


Given I'm not on Facebook, the latter bar is infinitely high.

As per the PGP description:

---
There are several levels of confidence which can be included in such 
signatures. Although many programs read and write this information, few 
(if any) include this level of certification when calculating whether to 
trust a key.

---

And that's the problem - as long as endorsements are equal, they're only 
as good as your weakest one.


Joe

Re: pgp signing in van

On 9/6/13 5:09 PM, Ted Lemon wrote:
> This is what I mean by "a high bar."   Signing someone's PGP key
> should mean "I know this person as X," not "this person is X."

I have no idea what "should" means in this context.  It seems
to me, from looking at this discussion (as well as from other
discussions around this topic) that different people have
different trust models in mind with quite possibly no two alike.
I guess part of the question here is whether not PGP key
signatures entail the signer being willing to vouch that the
key holder is who they say they are.  I'm not sure why
"I know this person as " provides much more reliability
than someone asserting their own identity.

Melinda

Re: pgp signing in van

On Sep 6, 2013, at 8:21 PM, Melinda Shore  wrote:
> when you vouch for someone's identity - in an authoritative
> trust system - you're also vouching for the authenticity of
> their transactions.

This is what I mean by "a high bar."   Signing someone's PGP key should mean "I 
know this person as X," not "this person is X."

Re: pgp signing in van

On 9/6/13 4:10 PM, Ted Lemon wrote:
> On Sep 6, 2013, at 6:42 PM, Joe Touch  wrote:
>> I've noted elsewhere that the current typical key-signing party
>> methods are very weak. You should sign only the keys of those who
>> you know well enough to claim you can attest to their identity.

> This is a ridiculously high bar.   The bar should be about at the
> level of a facebook friend request.  

People's personal policies about Facebook friend requests seem
to be all over the map, so I'm not sure what that means in
practice.  I'm not sure that's a great model in any event, since
when you vouch for someone's identity - in an authoritative
trust system - you're also vouching for the authenticity of
their transactions.  Those transactions would also include
*them* making attestations about the identity of people you've
likely never heard of.

Melinda

Re: pgp signing in van