Subject: pgp signing in van

From: Randy Bush <[email-masked]>
Date: Fri, 06 Sep 2013 09:45:58 +0900

so, it might be a good idea to hold a pgp signing party in van.  but
there are interesting issues in doing so.  we have done lots of parties
so have the social protocols and n00b cheat sheets.  but that is the
trivial tip of the iceberg.

  o is pgp compromised?  just because it is not listed in [0] is not
    very strong assurance in these dark days.

  o what are the hashes of audited software, and who did the audits?

  o what are the recommended algs/digest/keylen parameters?

  o do we really need eliptical, or is that a poison pill?

  o your questions go here ...

randy

---

[0] http://www.nytimes.com/interactive/2013/09/05/us/unlocking-private-communications.html

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Sep 2013 22:27:12 -0400

>   o your questions go here ...

I think our problems now go a lot further. The NSA is allegedly spending
$250 million a year infiltrating vendors and standards bodies. They have
also been pretty aggressive in hiring IETF folk for various consulting
contracts.

The big risk I see here is that there is a lot of finger pointing and every
bad decision that was made in the past that delayed the deployment of
strong crypto is now considered prima facie evidence of being a mole.

Not being a US citizen I see no reason to allow the NSA a backdoor in
anything I do. But looking at the carelessness and incompetence with which
they have guarded their own secrets I would not be anxious to allow them
access to mine even if I was a US citizen.

Seriously, this type of activity is an attack on the trust that is
necessary for collaboration. I doubt that the people who design and deploy
these programs had the slightest understanding of or concern for the costs
or consequences of their actions.

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 05 Sep 2013 19:54:17 -0700

On 9/5/2013 5:45 PM, Randy Bush wrote:
> is pgp compromised?

PGP is a packaging method.  Absent grossly incompetent packaging -- and 
I've never heard claims that PGP or S/MIME were guilty of that -- my 
sense is that the interesting security mechanisms are the underlying 
algorithms.

Is there something about PGP that creates different exposures than 
S/MIME, in terms of those algorithms?  (Key management has obvious 
differences, of course.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: <[email-masked]>
Date: Fri, 6 Sep 2013 11:15:22 +0100

Surely, pgp signing in vain?

Don't know about you, but I value plausible deniability.

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

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Randy Bush [[email-masked]]
Sent: 06 September 2013 01:45
To: IETF Disgust
Subject: pgp signing in van

randy

---

---

From: Russ Housley <[email-masked]>
Date: Fri, 6 Sep 2013 09:18:34 -0400

Dave:

>> is pgp compromised?
> 
> PGP is a packaging method.  Absent grossly incompetent packaging -- and I've never heard claims that PGP or S/MIME were guilty of that -- my sense is that the interesting security mechanisms are the underlying algorithms.
> 
> Is there something about PGP that creates different exposures than S/MIME, in terms of those algorithms?  (Key management has obvious differences, of course.)

The biggest difference is PKI vs. web of trust.  You do not need a key signing event for a PKI -- you have already decided (or a vendor decided for you) to trust the Certificate Authority.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Sep 2013 13:17:44 -0400

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.

But, Randy, of what use is my signing your key, if you never use it?

I would happy to sign a key for a network personality who posts
signed message regularly to @ietf.org mailing lists.  I would simply give
them a nonce to sign.   (For awhile, I was convince [email-masked],
whose full name I did not know until Orlando, was a gestalt network
identity...)

My key is still available via finger [email-masked], and [email-masked]
is offline (I used to have a 286 in the corner), and has web of trust
signatures going back to 1994.
pub   1024R/B0C8713D 1994-11-08 <- it's a bit weak these days.
pub   2208R/FCA16F90 2006-10-10 <- new "modern" offline key.

We just put our GPG fingerprint into the MEMO part of a vcard,
http://zxing.appspot.com/generator/ or using qrencode
http://fukuchi.org/works/qrencode/index.html.en (in debian/ubuntu)

I suggest that perhaps this might be a useful way to exchange info:
   http://www.sandelman.ca/tmp/IMG_20130906_125920.jpg
one would take a picture of the other person with their QR code
and fingerprint.  It also just works to remember the names of new people!

(Sadly, I can't scan the QR code with my phone from the photo displayed
on my screen, but I can read the fingerprint)

Patrik has a blog post: http://stupid.domain.name/node/1323
that does exactly that.

ps: nice address book entry for ietf@ietf.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 06 Sep 2013 12:02:10 -0600

> We just put our GPG fingerprint into the MEMO part of a vcard,

Actually, vCard has a KEY field:

http://tools.ietf.org/html/rfc6350#section-6.8.1

Peter

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Sep 2013 14:51:15 -0400

Could we do smime as well?

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

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

Sent from my difference engine

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 15:34:08 -0400

> rather teach the smime doggie pgp like tricks than vice versa

The problem is getting your smime program to stop using CA keys and only use your local key as a CA key.   And someone would have to code up something to do all the certs.   It's not a bad idea in theory though, if it can be made to work.

---

From: Joe Touch <[email-masked]>
Date: Fri, 06 Sep 2013 15:42:13 -0700

>       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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Sep 2013 19:29:53 -0400

On Fri, Sep 6, 2013 at 3:34 PM, Ted Lemon <[email-masked]> wrote:

> The problem is getting your smime program to stop using CA keys and only
> use your local key as a CA key.   And someone would have to code up
> something to do all the certs.   It's not a bad idea in theory though, if
> it can be made to work
>

I am working towards doing both.

Point is that it would be very useful to be able to offer confidentiality
to a core of people in the developer community. There may not be a way to
make use of the data leaving Vancouver but there might be a way to use it
before London.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Sep 2013 19:33:30 -0400

> trust in WG-chairs and IESG members?

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.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 20:10:14 -0400

On Sep 6, 2013, at 6:42 PM, Joe Touch <[email-masked]> 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.  The PGP key signing model of attesting to legal identities is solving the wrong problem.    But you are right that we can't require this sort of thing in order for people to participate in the IETF.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Sep 2013 16:21:57 -0800

On 9/6/13 4:10 PM, Ted Lemon 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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 21:09:23 -0400

On Sep 6, 2013, at 8:21 PM, Melinda Shore <[email-masked]> wrote:
> 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."

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Sep 2013 17:24:37 -0800

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 <X>" provides much more reliability
than someone asserting their own identity.

Melinda

---

From: Joe Touch <[email-masked]>
Date: Fri, 06 Sep 2013 18:30:08 -0700

On 9/6/2013 5:10 PM, Ted Lemon wrote:
>> 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.
>

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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 06 Sep 2013 21:43:41 -0400

Phillip Hallam-Baker <[email-masked]> wrote:
>methods

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 22:17:07 -0400

On Sep 6, 2013, at 9:24 PM, Melinda Shore <[email-masked]> wrote:
> I'm not sure why

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.

---

From: Scott Brim <[email-masked]>
Date: Fri, 6 Sep 2013 22:18:51 -0400

On Sep 6, 2013 9:10 PM, "Ted Lemon" <[email-masked]> 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."

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 22:24:52 -0400

On Sep 6, 2013, at 10:18 PM, Scott Brim <[email-masked]> 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.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Sep 2013 18:35:49 -0800

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 23:04:18 -0400

On Sep 6, 2013, at 10:35 PM, Melinda Shore <[email-masked]> wrote:
> 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.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Sep 2013 19:12:58 -0800

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 23:25:03 -0400

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

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

> assurances about identity, etc.

Yes.   But it is still _very_ useful.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Sep 2013 23:39:59 -0400

> 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 [email-masked] 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.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 06 Sep 2013 23:45:59 -0400

> 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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 06 Sep 2013 23:48:33 -0400

> Trust where someone may be signing a key in all good faith but for the

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

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Sep 2013 19:50:28 -0800

> for defined purposes it works quite well.  With external CAs you never know 

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

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 07 Sep 2013 00:13:24 -0400

On Friday, September 06, 2013 19:50:28 Melinda Shore wrote:
> > 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.
> 

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

---

From: Pete Resnick <[email-masked]>
Date: Sat, 7 Sep 2013 09:20:30 -0500

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.

<p  style="snark" strength="0.5">
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?
</p>

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<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 7 Sep 2013 11:29:40 -0400

> 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 [email-masked], 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
[email-masked], does it really matter what is on the
government-issued I-D?

> Trust where someone may be signing a key in all good faith but for the

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Sep 2013 11:41:14 -0400

> to say, the semantics are reasonably well sorted-out, which is

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Sep 2013 11:57:16 -0400

On Sat, Sep 7, 2013 at 11:29 AM, Theodore Ts'o <[email-masked]> wrote:

> > I can be very sure that I have the right key for [email-masked]

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.

> whom we had met at other Linux conferences previously, so we knew who

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.

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

> know each other the best.

You want me to give up my coffee and biscuits?

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

> with a stamp, "I am an NSA stooge."  :-)

And some folk may well have been unwitting stooges.

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Sep 2013 12:21:16 -0400

On 9/6/2013 11:04 PM, Ted Lemon wrote:
> 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…

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Sep 2013 15:13:39 -0400

--On Friday, September 06, 2013 19:50 -0800 Melinda Shore
<[email-masked]> 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.
> 
> 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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Sep 2013 17:25:45 -0400

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

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.

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Sep 2013 17:33:45 -0400

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

    > 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 <[email-masked]>, Sandelman Software Works

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Sep 2013 21:50:19 +0000

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 08 Sep 2013 16:21:32 -0600

On 9/8/13 3:50 PM, Ted Lemon 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/

---

From: Hector Santos <[email-masked]>
Date: Sun, 08 Sep 2013 19:09:56 -0400

> analogy, but it's kind of like open carry for encryption.)

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.

-- 
HLS

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 08 Sep 2013 17:19:51 -0600

On 9/8/13 5:09 PM, Hector Santos wrote:
>>> 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.
>> 
>> 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
> 
> 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/

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 9 Sep 2013 01:38:21 +0200

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

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 05:28:55 +0100

There is no upside.

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

Lloyd Wood

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ted Lemon [[email-masked]]
Sent: 08 September 2013 22:50
To: Michael Richardson
Cc: IETF discussion list
Subject: Re: pgp signing in van

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 9 Sep 2013 09:38:47 +0200

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

---

From: Brian Trammell <[email-masked]>
Date: Mon, 9 Sep 2013 10:31:54 +0200

hi Hector, Peter, all,

On 9 Sep 2013, at 1:09, Hector Santos <[email-masked]> 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.  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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Sep 2013 06:27:44 -0400

> signers.  In itself, that isn't a problem with which the IETF

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
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 06:41:56 -0600

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Sep 2013 08:43:37 -0400

Ted Lemon <[email-masked]> wrote:
    > On Sep 8, 2013, at 5:33 PM, Michael Richardson <[email-masked]>

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

---

From: "John Levine" <[email-masked]>
Date: 9 Sep 2013 13:49:49 -0000

>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

---

From: David Conrad <[email-masked]>
Date: Mon, 9 Sep 2013 06:53:59 -0700

On Sep 9, 2013, at 1:31 AM, Brian Trammell <[email-masked]> 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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 13:58:34 +0000

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

---

From: "Anshuman Pratap Chaudhary" <[email-masked]>
Date: Mon, 9 Sep 2013 16:31:36 +0000

Chop? 

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

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 09 Sep 2013 13:02:40 -0400

Hi Peter,

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 11:12:31 -0600

On 9/9/13 11:02 AM, Cyrus Daboo 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/

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Sep 2013 13:14:14 -0400

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 <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----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-----
>

---

From: Scott Brim <[email-masked]>
Date: Mon, 9 Sep 2013 13:51:16 -0400

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.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Sep 2013 14:14:07 -0400

On Sep 9, 2013, at 1:12 PM, Peter Saint-Andre <[email-masked]> wrote:

> Signed PGP part

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

I''ve just added:
to my .sig file collection.

Wonder how many MUTs will become unhappy? :-P

W

--
It must be authentic: 
http://xkcd.com/1181/

W

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Sep 2013 08:09:08 +1200

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

---

From: Dan York <[email-masked]>
Date: Mon, 9 Sep 2013 16:11:32 -0400

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

+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  [email-masked]
http://www.danyork.me/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork

---

From: Dave Crocker <[email-masked]>
Date: Mon, 09 Sep 2013 13:15:52 -0700

On 9/9/2013 1:09 PM, Brian E Carpenter wrote:
>  I've just discovered that when

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

d/

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 20:17:36 +0000

> 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/…

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

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

---

From: Steve Crocker <[email-masked]>
Date: Mon, 9 Sep 2013 16:27:14 -0400

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 <[email-masked]> wrote:

> Yeah, the pragmatics of truly independent, distributed processing environments, with limited resources and fundamental human factors barriers really are quite shocking.
> 
> d/
> 
> 
> -- 
> Dave Crocker

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 20:30:05 +0000

> 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 thin…

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 09 Sep 2013 13:36:17 -0700

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Sep 2013 16:38:02 -0400

> Yes, they should have made that impossible.

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

---

From: Steve Crocker <[email-masked]>
Date: Mon, 9 Sep 2013 16:39:31 -0400

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Sep 2013 08:48:37 +1200

> 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 ke…

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Sep 2013 17:05:34 -0400

--On Tuesday, September 10, 2013 08:09 +1200 Brian E Carpenter
<[email-masked]> 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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 21:13:24 +0000

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

---

From: David Morris <[email-masked]>
Date: Mon, 9 Sep 2013 14:19:44 -0700 (PDT)

> 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

---

From: SM <[email-masked]>
Date: Mon, 09 Sep 2013 14:21:07 -0700

Hi Brian,
>that arrived with a PGP signature?)

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

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Mon, 09 Sep 2013 14:25:51 -0700

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 21:27:08 +0000

On Sep 9, 2013, at 5:19 PM, David Morris <[email-masked]> wrote:
> 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.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 21:29:18 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 21:35:13 +0000

On Sep 9, 2013, at 5:25 PM, Dave Crocker <[email-masked]> 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.

---

From: "John Levine" <[email-masked]>
Date: 9 Sep 2013 21:36:15 -0000

>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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 21:42:18 +0000

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

---

From: "John R. Levine" <[email-masked]>
Date: 9 Sep 2013 17:43:21 -0400

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

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, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Arturo Servin <[email-masked]>
Date: Mon, 09 Sep 2013 18:51:22 -0300

> 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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 09 Sep 2013 18:09:07 -0400

On Monday, September 09, 2013 21:36:15 John Levine wrote:
> >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.

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

Scott K

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 22:49:10 +0000

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Sep 2013 19:25:18 -0400

On Mon, Sep 9, 2013 at 4:27 PM, Steve Crocker <[email-masked]> wrote:

> Actually, I interpret the chemistry professor's comment in a different
> light.  It would be possible to design a system where:
>
> 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.

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2013 01:07:19 -0000

>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

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2013 01:11:51 -0000

>wrong to copy someone else's text to another machine, hence the need for

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2013 01:13:10 +0000

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

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

---

From: "John R Levine" <[email-masked]>
Date: 9 Sep 2013 21:26:42 -0400

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

> 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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2013 01:41:55 +0000

On Sep 9, 2013, at 9:26 PM, John R Levine <[email-masked]> wrote:
> happen?

Yes.

> Typical S/MIME keys are issued by CAs that verify them by

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

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

---

From: "John R Levine" <[email-masked]>
Date: 9 Sep 2013 21:53:14 -0400

> 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, o…

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

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,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Sep 2013 22:21:57 -0300

> 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Sep 2013 22:32:26 -0300

On 09/09/2013 05:17 PM, Ted Lemon 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.
> 

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
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2013 03:44:41 +0000

On Sep 9, 2013, at 11:36 PM, Paul Wouters <[email-masked]> 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.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 10 Sep 2013 08:53:16 +0200

On 10 Sep 2013, at 3:53, John R Levine <[email-masked]> wrote:

> 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

---

From: t.p. <[email-masked]>
Date: Tue, 10 Sep 2013 09:41:58 +0100

---- Original Message -----
From: "Richard Barnes" <[email-masked]>
To: "Peter Saint-Andre" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 09, 2013 6:14 PM

> 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

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 10 Sep 2013 13:08:37 +0200

> automagically import the certs from on incoming mail.

<advocacy type=MUA>
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. 
</advocacy>

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?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2013 13:03:55 +0000

On Sep 10, 2013, at 4:41 AM, t.p. <[email-masked]> wrote:
> for reasons of
> 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.

---

From: t.p. <[email-masked]>
Date: Tue, 10 Sep 2013 14:35:30 +0100

----- Original Message -----
From: "Ted Lemon" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: "Richard Barnes" <[email-masked]>; "Peter Saint-Andre"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 10, 2013 2:03 PM
> security, of course; html has far too many attack vectors to allow it
to

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.

<tp>

Ted

A URI in a plain text e-mail means what it says; a URI in <a ...   /> 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
</tp>

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Sep 2013 12:32:03 -0400

On Mon, Sep 9, 2013 at 9:41 PM, Ted Lemon <[email-masked]> wrote:

> 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 [email-masked]. 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.

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Sep 2013 23:36:31 -0400 (EDT)

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

Paul

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2013 17:18:11 +0000

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

This appears to be untrue.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Sep 2013 14:19:43 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2013 18:36:55 +0000

On Sep 10, 2013, at 2:19 PM, Phillip Hallam-Baker <[email-masked]> 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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Sep 2013 11:47:27 -0700

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

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Sep 2013 15:39:48 -0400

On Tue, Sep 10, 2013 at 2:36 PM, Ted Lemon <[email-masked]> 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.

---

From: "John R Levine" <[email-masked]>
Date: 10 Sep 2013 17:47:55 -0400

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

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, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: manning bill <[email-masked]>
Date: Tue, 10 Sep 2013 15:04:56 -0700

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:

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2013 22:06:12 +0000

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

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 10 Sep 2013 18:15:16 -0400

On Tue, Sep 10, 2013 at 05:47:55PM -0400, John R Levine wrote:
> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Sep 2013 18:50:02 -0400

On Tue, Sep 10, 2013 at 6:06 PM, Ted Lemon <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2013 23:45:38 +0000

On Sep 10, 2013, at 6:50 PM, Phillip Hallam-Baker <[email-masked]> 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... :)

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Sep 2013 10:28:51 +0000

On Sep 11, 2013, at 2:45 AM, Ted Lemon <[email-masked]> wrote:

> You don't need a conspiracy.   You just need to threaten the right person with jail.   

I don't think you'd even need the threats. 

"Hello, Mr. Lemon. Thank you for taking the time to see us. As you know, there are a lot of terrorists who as we speak are planning attacks against our country. Let me ask you something. Do you love your country? You know what, don't answer that. I don't go much for all that flag-waving myself. But you remember 9/11? 3000 people died there. And in Iraq 170 were killed in the last few months. Those are the same people, and they're as determined as ever. And do you think they're all in Iraq and Syria? I'm not supposed to tell you this" (looks around the room to make sure you're alone) "but just last month we arrested <insert Arab-sounding name here> right in Virginia with bomb components in his basement and plans for some key buildings in DC. You know how they coordinated their attacks? They used your mail service. And that is why we've come to you. Not so that America can win. What's winning, anyway? But because we're saving lives, hundreds of lives, both here and abroad. We need your help. Will you do this for America? For the innocent victims?"

Notice the important parts of that pitch. A sense of danger; Making the target feel either patriotic or a humanitarian; Sharing a "secret" with the target, making him part of the "inner circle". Making the target feel important, like "only your cooperation can help us stop the next attack". If this pitch is executed correctly, by the end, the target is asking for an NSL as CYA. I've seen this kind of thing done once years ago, but it was done very poorly and didn't work. 

> 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 m…

Yeah, I don't get those references to the NSA being in hot water. Polls get different results depending on how the question is asked, but they either show a slim majority against massive snooping or a very slim majority accepting massive snooping "if it's to fight terrorism". I don't see much in the way of massive pressure on the legislative or executive branch to stop it.

Yoav

---

From: SM <[email-masked]>
Date: Wed, 11 Sep 2013 08:41:19 -0700

Hi Yoav,
>I don't think you'd even need the threats.

[snip]

>Notice the important parts of that pitch. A sense of danger; Making 
>the target feel either patriotic or a humanitarian; Sharing a 
>"secret" with the target, making him part of the "inner circle". 
>Making the target feel important, like "only your cooperation can 
>help us stop the next attack". If this pitch is executed correctly, 
>by the end, the target is asking for an NSL as CYA. I've seen this 
>kind of thing done once years ago, but it was done very poorly and didn't work.

Yes.

My reading of Phillip Hallam-Baker's comment is that there isn't 
anything to worry about in relation to Comodo except that he does not 
have any knowledge about the operational side.  John Levine asked how 
likely they would risk their reputation.  Theodore Ts'o mentioned 
that there really is no incentive for them to do a good job.

Over the last few years nobody noticed that there might be a 
problem.  That's not reassuring.  I doubt that people would not 
comply with a NSL.

Regards,
-sm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Sep 2013 15:06:45 -0400

On Wed, Sep 11, 2013 at 11:41 AM, SM <[email-masked]> wrote:

>  Notice the important parts of that pitch. A sense of danger; Making the
>> target feel either patriotic or a humanitarian; Sharing a "secret" with the
>> target, making him part of the "inner circle". Making the target feel
>> important, like "only your cooperation can help us stop the next attack".
>> If this pitch is executed correctly, by the end, the target is asking for
>> an NSL as CYA. I've seen this kind of thing done once years ago, but it was
>> done very poorly and didn't work.
>>
>
> Yes.
>
> My reading of Phillip Hallam-Baker's comment is that there isn't anything
> to worry about in relation to Comodo except that he does not have any
> knowledge about the operational side.  John Levine asked how likely they
> would risk their reputation.  Theodore Ts'o mentioned that there really is
> no incentive for them to do a good job.
>

Since the operations side is in Salford UK, a National Security Letter
would have no force there.

I am not aware of any similar provision in UK law which is in any case
constrained by European Union privacy law, European Human Rights law etc.

And it is a firmly established principle of English law that the courts
cannot interfere with any action in parliament and that an injunction
obtained in England has no effect in Scotland (yes really). So if people
are really worried, get me tickets to the Edinburgh festival and return
airfare and we can have a talk. But you would probably be disappointed by
what I had to say. If I did have something to say I would go talk to one of
the members of parliament I know from university, school, family, etc.

Incidentally the worst British judge of the 20th century is no longer on
the bench and the super-injunction stupidity has come to an end with his
career.