Subject: Agenda, security, and monitoring

From: John C Klensin <[email-masked]>
Date: Sat, 01 Feb 2014 18:18:11 -0500

Hi.

After looking through the agenda and thinking about end to end
confidentiality mechanisms, a few questions/suggestions:

(1) Other than a probably-appropriate level of general paranoia,
do we have
any reason to believe that PGP (Symantec and/or GNUPG versions)
has been
sufficiently compromised to not provide a good defense against
either
pervasive surveillance or general snooping?

(2) If the answer is "no, they are probably ok" or better,
should we be
doing a key signing in London?  That would facilitate longer
keys for those
who would benefit from that and getting the facilities more
generally
available to relative newcomers [1].

(3) If the answer is "yes, they have to be treated with great
suspicion",
they why are there not BOFs or other sessions on the agenda to
consider
whether the IETF standards should be upgraded or, if that is not
feasible,
deprecated?

(4) If we are going to do a key signing, would there be enough
interest in
signing of CACERT X.509 keys to see if there are enough people
with the
right credentials who will be in London to certify those too (in
spite of
the non-presence of the CACERT root keys in various browsers,
etc.)?

If we are really serious about preventing monitoring, especially
at the
application layer and doing so within our own community as an
example, this
should be obvious.  Indeed, it might be interesting as a first
step to fix
the IETF list so it wouldn't accept unsigned messages.
Conversely, if it
is not obvious, maybe we are not really that serious.

   best,
    john

[1] Some people will sign PGP keys on the basis of documents
(like
passports) alone, others won't.  But, even if most people won't,
it has
been a sufficiently long time since we've done a key-signing at
IETF that I
imagine there are a number of no-longer-newcomers around who
might benefit
and who are reasonably well known to others .

---

From: Dave Crocker <[email-masked]>
Date: Sat, 01 Feb 2014 15:34:46 -0800

> pervasive surveillance or general snooping?

1. It has demonstrated unacceptable usability for average users.

2. It does not protect the header or the envelope, to the extent anyone 
cares about divulging the Subject or other message meta-data...

3. It's packaging in the body is ugly. (See #1)

For sufficiently motivated and technical individuals, it's clear the 
technology is extremely useful as a discrete capability.

However any focus on PGP or S/MIME in their current forms will be a 
distraction that well might seduce the IETF community into thinking it's 
doing something useful for the Internet that actually isn't.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Sat, 01 Feb 2014 19:35:33 -0500

--On Saturday, February 01, 2014 15:34 -0800 Dave Crocker
<[email-masked]> wrote:

>> (1) Other than a probably-appropriate level of general
>> paranoia, do we have
>> any reason to believe that PGP (Symantec and/or GNUPG
>> versions) has been

Agree completely, but that wasn't the question.  

Noting the email systems with which we are both familiar as
examples and the history of attacks (whether technical or
legal-judicial) on intermediate systems (relays and otherwise),
if we are asked today what our best end to end technology
options are, those are it.  The acceptability part is, at least
IMO, a combination of a "not needed enough to be worth the
trouble" and the difficulties of managing public, and especially
private, keys.  For the first, I suspect that there are a lot
more people in the world who care enough to go to extra trouble
than was the case a year or so ago.  We could debate whether "a
lot" is actually large enough to be a significant number, but
even if I agreed that it was not, I would rather tell a
concerned user "the best technology we have is annoying  and
will require you and your correspondents to learn more, and fuss
more, than you would probably like" than "if you can't trust
your email provider, its choice of relays, and any relevant
governments, you are screwed and the IETF is ok with that".

> 2. It does not protect the header or the envelope, to the
> extent anyone cares about divulging the Subject or other
> message meta-data...

Extending from and building on my comments above, is your
preferred alternative "sending email is hopeless; if you don't
want to be monitored, you should go back to something secure
like smoke signals (uh, whoops)".  For many purposes, if one has
a choice between solid content protection with no or weak
envelope protection and no protection at all, the answer is
obvious.  Conversely if one had good envelope protection that
provided only hop-by-hop content protection, the two sets of
methods could be combined if that were felt to be needed.

> 3. It's packaging in the body is ugly. (See #1)

Yep.  And if one didn't want to tolerate ugly in order to get
more privacy, then one doesn't need the privacy enough.  See
above.

> For sufficiently motivated and technical individuals, it's
> clear the technology is extremely useful as a discrete
> capability.
> 
> However any focus on PGP or S/MIME in their current forms will
> be a distraction that well might seduce the IETF community
> into thinking it's doing something useful for the Internet
> that actually isn't.

Because of my concerns about compromised mail system operators,
relay servers and even submission and delivery servers, plus the
vast majority of users who do not control the domains they user
for email, I could say much the same thing about all of the work
that is going on about hop-by-hop methods, especially
domain-dependent ones.  But I don't feel that way: I don't think
there are any completely effective methods out there (in terms
of, e.g., protection of both envelope and content against
attackers with legal authority).  So, for me, the choice is
between deploying a variety of mechanisms, understanding and
being clear about the applicability and limitations of each, and
saying things that amount to "hopeless".  

All of that said, I wasn't proposing a "focus on PGP or S/MIME"
or anything like it.  I was proposing a convenience and enabler
for those members of our community who felt like using those
methods or, if the techniques we have standardized are actually
defective, that we either fix them or, depending on the level of
risk, either generate Applicability Statements or deprecate the
things.  Certainly having IETF standardized security-related
protocols out there that we consider unacceptable without doing
something about it is inconsistent with our claimed interest in
mitigating pervasive surveillance.  And that is really all I
said.

regards,
   john

---

From: Randy Bush <[email-masked]>
Date: Sun, 02 Feb 2014 10:02:57 +0900

i support pgp key signing even though pgp and signed mail are not
perfect or make cash fall from the sky.  one day at a time.

i am not sure how well the normal signing party will scale to the
crowd likely to be attracted at an ietf meeting.  perhaps a more
distributed asynchronous protocol?  though i personally get a lot
of value in seeing how rigorously alice checks bob's credentials,
and mark my trust in alice accordingly.

there are folk who are good at key signing parties/protocols, so i
will not presume to grab management of this.  but if i can help,
holler.

randy

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 02 Feb 2014 02:27:33 +0000

Hi John,

On 02/01/2014 11:18 PM, John C Klensin wrote:
> (1) Other than a probably-appropriate level of general paranoia, do
> we have any reason to believe that PGP (Symantec and/or GNUPG
> versions) has been sufficiently compromised to not provide a good
> defense against either pervasive surveillance or general snooping?

That's two questions. IMO, neither S/MIME nor PGP provide
highly effective protection against pervasive monitoring (PM).
Either can be pretty good against "general snooping." In
both cases the protocol crypto is, as far as we know, just
fine. Both protocols (PGP and S/MIME) however were designed
in a different time, when an enterprise security mode was
far more often an accurate description of most Internet users'
reality, so that's not that surprising.

So there's no yes/no answer to your question(s) #1.

> 
> (2) If the answer is "no, they are probably ok" or better, should
> we be doing a key signing in London?  That would facilitate longer 
> keys for those who would benefit from that and getting the
> facilities more generally available to relative newcomers [1].

I'm fine to help get a room, if someone else takes on the
organising.

> suspicion", they why are there not BOFs or other sessions on the
> agenda to consider whether the IETF standards should be upgraded
> or, if that is not feasible, deprecated?

I think the lack of BoFs is because end-to-end interpersonal
messaging and how to make that resistant to PM is a
significantly hard problem. And there is also the issue that
there are plenty of reasons why various folks (e.g. advertisers,
not just govt.) would rather that interpersonal messaging were
not secured end to end, so it seems the people with significant
deployment also lack motivation, to say the least.

I do however think the XMPP folks are doing the right things
as far as I can see.

We are however having a workshop [1] before IETF-89 that will
discuss this and other topics related to PM. (Sorry, its
already oversubscribed, but we'll be reporting on it at the
saag session.)

  [1] https://www.w3.org/2014/strint/

> interest in signing of CACERT X.509 keys to see if there are enough
> people with the right credentials who will be in London to certify
> those too (in spite of the non-presence of the CACERT root keys in
> various browsers, etc.)?

No idea personally.

> If we are really serious about preventing monitoring, especially at
> the application layer and doing so within our own community as an 
> example, this should be obvious.

I disagree as it happens. Putting an emphasis on identification
and authentication seems backwards to me. First, we ought try
provide means to communicate that resist PM, (which requires
confidentiality and can use some help from Mr. Data Minimisation:-)
and after we have that nicely unerway, we can then see how to
establish various kinds of authentication.

I don't believe that starting from authentication is at all
the right approach.

But, I might be wrong, so happy to see people signing keys.

> Indeed, it might be interesting as a first step to fix the IETF
> list so it wouldn't accept unsigned messages.

Wasn't that debated a few months ago. I don't think that
would be at all useful for anyone.

> Conversely, if it is not obvious, maybe we are not really that
> serious.

No. Being serious about PM does not mean wanting to start
by identifying and authenticating everything in sight. I've
deliberately put that in an argumentative way, but I hope
it makes it clear why we really need to start from
confidentiality and mechanisms like minimising the PII in
our protocols.

Cheers,
S.

> 
> best, john
> 
> [1] Some people will sign PGP keys on the basis of documents (like 
> passports) alone, others won't.  But, even if most people won't, it
> has been a sufficiently long time since we've done a key-signing
> at IETF that I imagine there are a number of no-longer-newcomers
> around who might benefit and who are reasonably well known to
> others .
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Sat, 01 Feb 2014 18:38:18 -0800

> perfect or make cash fall from the sky.  one day at a time.

After twenty years of one day at a time, it's demonstrably not the 
vehicle for mass-adoption, nor is there any basis for viewing it as the 
foundation of the vehicle.

If you think otherwise, please offer an explanation of how to get from 
the small-scale, long-term here to the the necessarily very large-scale 
there that we need to reach.

Again, putting energy into PGP or S/MIME -- in anything like their 
current form -- incurs extremely expensive opportunity costs for the 
IETF community.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 02 Feb 2014 02:44:36 +0000

> current form -- incurs extremely expensive opportunity costs for the

You may be right, but I'm not so clear about that, as stated.

If someone wanted to propose using PGP or S/MIME (aka CMS) formats
to provide closer-to-end-to-end confidentiality protection for email
messages that covered most headers in a way that might get deployment
then I think that would not match your description. I do suspect
that that is not likely to happen.

If OTOH, we spent a lot of time debating email message origin
authentication then I fully agree with you that we'd just be
distracting ourselves pointlessly.

S.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 01 Feb 2014 19:21:27 -0800

> that that is not likely to happen.

1.  Very much not likely.

2.  It's unrelated to the parts of such a service that appear to be the 
major barriers to large-scale use

3.  It's the wrong level of design discussion, at this stage.

> distracting ourselves pointlessly.

+1

d/

---

From: John C Klensin <[email-masked]>
Date: Sun, 02 Feb 2014 00:18:14 -0500

--On Sunday, February 02, 2014 02:27 +0000 Stephen Farrell
<[email-masked]> wrote:

>...
>> If we are really serious about preventing monitoring,
>> especially at the application layer and doing so within our
>> own community as an  example, this should be obvious.
> 
> confidentiality and can use some help from Mr. Data
> Minimisation:-) and after we have that nicely unerway, we can
> then see how to establish various kinds of authentication.
> 
>> Indeed, it might be interesting as a first step to fix the
>> IETF list so it wouldn't accept unsigned messages.
> 

Sorry, I wasn't clear.  At least in this particular context, I
have no interest at all in authentication.  My interest was in a
demonstration of the ability to handle encryption.  For S/MIME
and PGP, if I can sign a message, I can decrypt a message that
is sent to me.  From a privacy or surveillance resistance
standpoint, the latter, and a way to demonstration That
capability, are important.  Authentication is irrelevant and, as
you say, not helpful in that context.

   john

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 02 Feb 2014 09:48:27 +0100

> 1. It has demonstrated unacceptable usability for average users.

At last my view and experience is that latest Enigmail and MacGPG is
making it usable.

The key exchange is hard, but works really well in Enigmail+Thunderbird,
as key management is directly from mail read/compose window. Not in a
separate application.

> cares about divulging the Subject or other message meta-data...

Correct. It only protects what it protects.

> 3. It's packaging in the body is ugly. (See #1)

Huh?

It is using multipart/signed just like other security mechanisms that
protects the body.

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Sun, 02 Feb 2014 00:54:04 -0800

> as key management is directly from mail read/compose window. Not in a

You think that's a system that can and will be convenient and used by 
the mass market???

So why isn't it already?

> It is using multipart/signed just like other security mechanisms that

Take a look at the message that John posted, opening this thread.  That 
some systems use multipart/signed is fine, but it's not what's most 
common for PGP.

d/

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 02 Feb 2014 10:00:17 +0100

> You think that's a system that can and will be convenient and used by

Several reasons, but specifically two:

A. Even people like we engineers (just look at your message) is unaware
of the good software that is out there

B. It is not supported by Microsoft/Outlook out of the box

> some systems use multipart/signed is fine, but it's not what's most

I disagree.

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Sun, 02 Feb 2014 01:16:52 -0800

On 2/1/2014 4:35 PM, John C Klensin wrote:
>>> do we have any reason to believe that PGP (Symantec and/or GNUPG

Yeah, effectively it was.  You suggested activities such as PGP 
key-signing.  My point is that that has nothing to do with providing 
meaningful PM protections for the Internet.

You almost asked whether the PGP/SMIME model and algorithms were still 
believed to be sufficient.  That, of course, would be useful background 
for meaningful technical work on PM, but that's a very focused and very 
brief question and not at all the path the rest of your message went down.

> options are, those are it.

Being able to demonstrate that we know how to encrypt the message body 
is fine, but in terms of current concerns over PM and the nature of what 
needs to be done, it seems like a point working very hard for 
triviality, along with being able to say that we can send data reliably. 
  Essential, but not noteworthy.

>     For the first, I suspect that there are a lot

It isn't, but more significantly, it doesn't matter.

We have plenty of experience with events at the level of catastrophes 
that then produced no meaningful change in operator or user behavior. 
In other words, the lesson was not learned.  I'll point to the study 
done a year after the Morris Worm as an early example, in a far more 
tech-savvy Internet operations world:  No significant change in server 
protection.

> preferred alternative "sending email is hopeless;

No.

More specifically, my preferred alternative is that we focus on creating 
solutions, rather than worrying about spending energy on mechanisms that 
have already failed to scale.

I've more than once registered this preferred alternative generally, 
which is to look at this topic in an integrated fashion, identify 
system-level requirements and system-level barriers to adoption.

And since earlier this evening a private exchange prompted my fleshing 
this out a bit, here's what I mean, in more detail:

    1.  What information needs to be protected?

      "Raw payload" is the least interesting answer.  Not that it's 
wrong, but it's the most obvious.  Saying PGP is a version of saying raw 
payload.  That's why I pushed back so strongly on that.

     I'd expect the interesting discussion to be about

        a)  Describing information that is used for identity correlation

        b)  Packaging/header/envelope protection

        c)  Traffic/activity analysis protection

    2.  What are the broad strokes of mechanism(s) that will protect 
what needs protecting?

     This is somewhere between a conceptual requirements statement and a 
functional spec.  It's most certainly not a detailed statement.  The 
intent is to define the solution space, to guide the specification effort.

    3.  On the premise that we already have extensive experience with 
all of the relevant component technologies (keys, key management, 
encryption, authentication, etc., etc.) then what appears to be the 
major barriers for large-scale solutions?  In the realm of key 
management, it well might be that we do /not/ have sufficient experience 
with usable solutions.

    4.  How do we overcome #3?

That's probably a good, high-level start.  If we make progress on these, 
we will have quite a bit of guidance for detailed design efforts, or at 
least experiments.

> more privacy, then one doesn't need the privacy enough.  See

When I constantly  comment that the IETF needs to stay away from making 
assertions that touch on usability topics, it's always nice to get such 
solid demonstrations of why.

Such dismissals of mass-market adoption and use realities really does 
more to show the IETF community's failings, far more than end users'.

> that is going on about hop-by-hop methods, especially

Yup.

>   So, for me, the choice is

You appear to be applying a constraint of having to work with what 
exists.  If we had sufficient solutions available that would be fine, 
but we already know we don't.

So wouldn't it be really nice if there were a savvy engineering 
community that might actually focus on developing /new/ techniques to 
deal with PM?

Where might we look for such a group?

> for those members of our community who felt like using those

Oh.  You weren't concerned with the larger Internet.  You just wanted 
IETF folk to feel more secure (when talking with other IETF folk?)

> risk, either generate Applicability Statements or deprecate the

Glad to hear that we can resolve the considerable concerns about PM with 
some applicability statements and no actual engineering.

d/

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Sun, 2 Feb 2014 08:54:58 -0500

> On Feb 1, 2014, at 18:18, John C Klensin <[email-masked]> wrote:
> 
> Indeed, it might be interesting as a first
> step to fix

I don't think this is a good idea.

First, it would raise technical barriers to participation; now one would have to install software other than email software, configure it correctly and point ietf to the signing key (no?)... (unless the list doesn't do an actual sig check, in which case what's the point?). Second, while I and others are comfortable with a default-sign policy, I know many more people that are very picky with non-repudiability and things they cryptographically sign. Finally, I'm not comfortable keeping keys on mobile devices (signing or otherwise), which would mean emails I send from those devices like this one will not be signed.

Am I missing something? I can imagine many of us have longer keys since the last IETF, so I'd definitely be interested in a signing event.

best, Joe

--
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
https://www.cdt.org/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 2 Feb 2014 10:34:45 -0500

On Sun, Feb 2, 2014 at 3:54 AM, Dave Crocker <[email-masked]> wrote:

> You think that's a system that can and will be convenient and used by the
> mass market???
>
> So why isn't it already?

I address that in my video. Sorry, its not in text yet, but the argument is
not really part of the technical specifications.

The part that you don't state by name but imply is 'what is the business
model'. We are talking about a multi-million dollar change to the email
infrastructure. That is only justified if we can show a multi-billion
dollar return on the investment.

I think that there is such a return. If my bank, my doctor, my brokerage
can send mail and be assured that the transport is confidential end to end,
they can use email in more ways. SSL made Web commerce possible and added
roughly five trillion dollars to global GDP according to one estimate.
Email security can make Internet commerce better and simpler and sustain
that growth. Even if the additional benefits from making the other Internet
killer application secure are 1% of the Web benefits, that is a lot of
potential.

I see S/MIME and PGP as being 95% right respectively. The problem is that
Internet applications don't take off if they are 'pretty good' back in 1992
they had to be extremely good. And now they have to be exceptionally good.

Most of us have a box full of smartphones we bought before the iPhone came
out. The Palm Treo, HP iPaq and the Rim pager. They were all functional but
none of them had the real web, they were all walled gardens. Remember that
before the iphone the industry was flushing a billion dollars a year down
the WAP toilet in the confused belief that what cell phone users really
wanted was a dumbed down version of the Web with more adverts.

That missing 5% is critical. Specifically any new security scheme has to be
frictionless:

* Key Management: Has to make starting a key set simple and intuitive. The
user cannot be required to perform annual maintenance to replace expired
certificates. Everything has to be completely automatic.

* Multiple devices: It must be really easy to read the encrypted mail on
the many devices real users use today. I have eight machines that I
regularly read email on. Making it possible to read mail on a new device
has to be a one or two clicks affair.

* Transparent: Sending mail securely has to take no more effort that
insecure mail. That means that the mail client (or a proxy) has to decide
whether to send mail in cleartext or encrypted. Which in turn means that
there has to be a mechanism for specifying security policy.

S/MIME already supports an enveloping mode that protects the headers and
metadata. It just isn't fully supported by the deployed base. So there has
to be a way for a receiver to tell the sender what they support. Which is
why we can't use the PGP or S/MIME infrastructure just as is, we need to
add a little policy glue.

> some systems use multipart/signed is fine, but it's not what's most common
> for PGP.

One of the biggest problems we have is that rather than tell PGP and S/MIME
to use a common packaging format and compete on the trust model, both
groups were told they could go ahead independently (although Jeff Schiller
told me that PGP was "not allowed to develop a PKI" then he rolled his
eyes).

End-to-end email has stalled in part because of the S/MIME vs PGP standards
war. PGP has ended up with all the mindshare, S/MIME has the deployed base.
When I was at VeriSign I had some long discussions with Jon Callas about
what might we do to fix things and come to a common platform. The division
was particularly silly when PGP had one of the best S/MIME platforms in the
market. That effort was overtaken by events and DKIM. The industry didn't
have bandwidth for two email crypto efforts at once. When I left VeriSign I
lobbied PGP inc to start a CA precisely to see if we could start to heal
the rift. Not that it helped. Symantec now own both companies and that
hasn't helped either.

If people want to move forward on this, something that would be very
helpful is for the naysayers to put all their objections into an Internet
Draft. Then those of us looking to solve the problem can go through and see
what we have solved and what is left to do.

I wrote a set of IDs as design documents before starting work on the code:

http://tools.ietf.org/html/draft-hallambaker-prismproof-req-00
http://tools.ietf.org/html/draft-hallambaker-prismproof-key-00
http://tools.ietf.org/html/draft-hallambaker-prismproof-dep-00
http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00

I now have code that is incomplete but shows proof of concept:
http://sourceforge.net/projects/prismproof/

There are two phases to the code:

Phase One is a scheme that employs a direct trust model and requires no
trusted third parties or infrastructure beyond the existing email
infrastructure and access to a Web Server to publish the Phingerprint
Blocks. This scheme uses the 'strong email address' which is essentially a
PGP fingerprint prepended to a mail address.

Phase Two allows people who have not met directly to exchange secure mail.
This scheme allows people to use their normal email address without any
visible cryptogunk. It necessarily relies on some form of infrastructure
but does not force a peer-to-peer or hierarchical model.

Right now the proxy can generate and manage keys, accept outbound mail,
encrypt it and forward it to the actual outbound mail server. I hope to get
the code to the point where it can make the decision to encrypt or not and
pull keys from a web server before London.

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

---

From: Scott Brim <[email-masked]>
Date: Sun, 2 Feb 2014 10:54:43 -0500

Even if it's easy to use (and I'm grateful for enigmail and other
tools), PGP still has the problem of trust dilution.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Feb 2014 11:04:01 -0500

> tools), PGP still has the problem of trust dilution.

Trust dilution really isn't a problem for most of the things you'd want to use PGP for if it were ubiquitous.   For the cases where it is, like bank transactions, stronger key validation is (a) needed and (b) possible, because its use cases provide the leverage needed to make it work.

The problem with PGP now is that it's _not_ ubiquitous, so the only thing you can use it for is use cases where you really need strong trust.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 2 Feb 2014 11:26:23 -0500

> tools), PGP still has the problem of trust dilution.

We can change the trust model.

The PGP model does not meet enterprise needs. If I am sending a mail to an
IETF mailing list it is from me. But if my bank manager is sending me an
email it is coming from the bank not me. So there is a requirement for a
hierarchical trust model to support hierarchical organizations.

The S/MIME model requires trusted third parties but does not give them an
opportunity to add a lot of value unless the network of secure mail users
is a lot larger than it is.

PGP and S/MIME both present a false dichotomy between two trust models when
we actually need both. And saying that it is possible to kinda-sorta use
one to support the use of the other really doesn't fly. Its trying to use a
screwdriver as a hammer.

---

From: "John Levine" <[email-masked]>
Date: 2 Feb 2014 15:38:17 -0500

>B. It is not supported by Microsoft/Outlook out of the box

Hi, Outlook 365 user here, signing my mail with S/MIME, no plugins or
anything needed. Where¹s all the rest of the signed mail?

Of course, getting the fripping cert into Outlook was quite exciting, and
involved sending at least one crash report to Microsoft. Perhaps there are
other issues, some of which may even have been discussed to death over the
past 15 years.

R¹s,
John

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 2 Feb 2014 16:46:56 -0500

> 1. It has demonstrated unacceptable usability for average users.

This is much more of an integration issue than anything else, I think.

For example, both S/MIME and GPG support is well integrated into mutt,
such that it is quite easy to use.  It's literally 2 or 3 keystrokes
to request that a message be PGP signed or encrypted.

If you haven't looked to see how the implementations have gotten
better over the past couple of years, you may be quite surprised how
much better things have gotten.  For example, I was extremely
pleasantly surprised to find out how easy it was to buy[1] a 16 Euro
OpenGPG smartcard[2], and to start using it.  I didn't have to do any
driver configuration or software recompilation.  It just worked[tm].

[1] http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=42
[2] http://g10code.com/p-card.html

So now my GPG private key is stored on a smartcard, and is no longer
on my laptop hard drive.  (The same is true for my ssh private key ---
the gpg-agent also will handle ssh keys.  Major win!)

> 2. It does not protect the header or the envelope, to the extent
> anyone cares about divulging the Subject or other message
> meta-data...

This is true for both S/MIME and GPG.

> 3. It's packaging in the body is ugly. (See #1)

You can package up PGP signatures using PGP/MIME, at which point it is
just as ugly as MIME (and S/MIME) happens to be.  Which is to say, if
you have a mail agent which supports the MIME format (I use mutt), you
won't see the ugliness at all.

The one pain point is that if I know I'm exchanging encrypted mail
with someone for which I happen to know their mail agent doesn't
understand PGP/MIME, I have to go slightly out of my way to select the
legacy "BEGIN PGP MESSAGE" body format.

But then again, if I want to exchange encrypted mail with someone
whose mail user agent doesn't support S/MIME (or who didn't feel like
paying $$$ to some certifying authority, many of which have failed
spectactular in the past), I don't have any recourse at all.  At list
with PGP/GPG I have my choice of either PGP/MIME or the traditional
inline body format.

> distraction that well might seduce the IETF community into thinking
> it's doing something useful for the Internet that actually isn't.

If more internet developers actually used GPG or S/MIME, maybe we
could start focusing on the real problem, which isn't in how we do the
crypto, but how we do the key management, and/or figuring out how to
solve the CA "race to the bottom" problem.

						- Ted

P.S.  I would **really** strongly suggest that people consider
experimenting with the OpenPGP smart card.  If you have a Lenovo
laptop which you configured with the extra $20 smartcard reader
option, it's amazingly convenient from a hardware usage standpoint,
and as I mentioned, I was amazed how little work I needed to do to
make my Debian laptop use it.

If you need to purchase an external $20 USB smartcard reader (and
there are portable ones that when folded are only 48mm x 20mm x 12mm
-- see [2]) it's a little bit less convenient, but the piece of mind
in knowing that your crypto keys are very well protected is well worth
it IMHO.

[2] https://www.scbsolutions.com/express/product_info.php?cPath=1&products_id=119&SCBtid=34f590521dbb61a86a0476833b38413c

The one annoying thing is that the cards are shipped from Germany.
Maybe someone would be willing to do a bulk buy and bring them to the
next IETF meeting, if there is sufficient interest.  As I mentioned,
it can be used to protect both your PGP and SSH private keys.

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 03 Feb 2014 00:28:33 +0000

Hi all,

this might be a totally stupid question, but I am gonna ask it anyway:
I know it is not as sexy as end point encryption, but we could also
concentrate on just filling the last gaps of a fully functional
encryption on all hops (clientA->mailserverA->mailserverB-clientB).
Recently, I get the feeling the maturity of mail-servers, DNS etc. could
actually allow for a worldwide deployment of this. And current levels of
spam and mass surveillance might be the trigger points needed to get
that widely deployed if we fill in a few minor gaps.
Today, basic client to server encryption is fairly trivial and already
widely in use.
And we could also work to get a predominant mail-server to mail-server
encrypted connection for all nodes, using TLS and certs pinned for the
domain read from DNS (or DNSSEC) or on first connect. That could
probably raise the efforts for pervasive mail eavesdropping quite a bit.

I know it is not as good as end-point to end-point encryption, and your
mail server and the recipient's mail server would still need to be
trusted systems, but it would be totally transparent for normal users
(which PGP is not) and the effort to get this done and deploy this
worldwide might be reasonable low. Plus it might have the added benefit
of reducing spam as well.

Just a thought.

Tobias

On 01/02/14 23:34, Dave Crocker wrote:
> anyone cares about divulging the Subject or other message meta-data...
>

---

From: Pete Resnick <[email-masked]>
Date: Sun, 2 Feb 2014 18:44:58 -0600

> you say, not helpful in that context.

I agree that authentication is irrelevant in this context. But that's 
leads me to agree with Dave on a central point (hence the little I-D 
we've been banging on and submitted to the STRINT folks): The problem 
with PGP and S/MIME is that they require authentication in order to 
start using encryption, and since authentication is both irrelevant to 
this *and* a pain to do, I don't think it's likely that mechanisms that 
require authentication to get started are good candidates to address PM, 
let alone be a terribly good demonstration that we can do encryption. I 
can't get torqued about people participating in a key signing: If you're 
interested in using those tools, go for it. But I do think that if we 
want to make headway on the PM problem and convince people that we can 
address pieces of it, we need to start looking at different sorts of 
mechanisms.

I suspect Ted might be right and this is simply an integration problem. 
I'm not sure whether Dave agrees or disagrees with me on this, but I 
think we've got the tools in our toolbox already: The bones (and much of 
the meat) of PGP or S/MIME might be perfectly suitable with some 
re-working. But I think until that re-working is done, we're not likely 
to have a good demonstration of this stuff actually working, especially 
if "the best technology we have is annoying  and will require you and 
your correspondents to learn more, and fuss more, than you would 
probably like".

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 03 Feb 2014 02:18:38 +0100

> make my Debian laptop use it.

I want to point at the Youbikey that start to get some interesting
features. Many of you know Simon Josefsson that works with this, and
some even know Stina Ehrensvärd, nowadays living in northern CA.

<http://www.yubico.com/2012/12/yubikey-neo-openpgp/>

Seems you John triggered some interest in at least some sharing and
hacking of "interesting things" that (which I strongly support) makes us
who are "geeks" try the various new things that exists. And that way we
will as always in IETF hopefully bring more usable tools and features
into whatever systems we work with.

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Feb 2014 04:44:04 -0500

--On Sunday, February 02, 2014 18:44 -0600 Pete Resnick
<[email-masked]> wrote:

> The problem with PGP and S/MIME is that they require
> authentication in order to start using encryption, and since
> authentication is both irrelevant to this *and* a pain to do,
> I don't think it's likely that mechanisms that require
> authentication to get started are good candidates to address
> PM, let alone be a terribly good demonstration that we can do
> encryption.

Pete,

Perhaps I'm missing something, but it seems to me that, if one
is willing to rely sufficiently on the email system to say "this
will get to the intended person (or at least mailbox), and, if
it does, the person who opens it will either have the relevant
key to be able to read it or not and, if they don't that is ok",
then all that is needed is a self-signed key (or self-signed
X.509 cert).  That is basically "key but no authentication".
Put differently, we _always_ rely on authentication -- if I send
mail to "[email-masked]", I'm making a whole series
of assumptions that it is you, that such mail will reach you and
only trust-able others, and so on.  Those assumptions are fairly
weak and certainly don't involve independent certification, but
that is about the strength and quality of the authentication,
not whether authentication is assumed or not.

Put differently, unless my 30 second approximation to a threat
analysis missed something, it provides about the same level of
authentication as "I can buy a domain name without showing any
identity evidence other than the ability to make payment, I can
get a certificate issued on the basis of being able to set a
mailbox and appropriate DNS records to receive mail at that
domain and/or can publish keys as part of that domain record".
Like those [other] domain-based approaches, it is going to be
pretty good in practice unless an attacker has the ability to
either subvert a registrar [1] or, perhaps, to intercept and
divert (or copy) traffic en route [2].

Again, with either PGP or S/MIME (and X.509) with a self-signed
cert or key, authentication is not needed to start using
encryption, only a (perhaps implicit) belief on the part of the
sender that, if the recipient can advertise a public key, it
probably has the private one and that the key-advertiser is not
the proverbial entity-in-the-middle.

Of course, those of us who prefer a somewhat higher degree
(and/or out of band) of assurance than the entity we are
communicating with is the intended one will need authentication
and authentication strong enough to be convincing for our
purposes.  That is, as you suggest, a separate issue and more of
a pain.  It may be inconsistent with legitimate anonymity.  For
those who want it, bringing people together for key signing may
be helpful.  It may be especially helpful for anyone who
believes that "appears to be human, has a face, registered for
IETF, and can find the room in which a key-signing is to occur"
[3] is a better minimal credential than "was able to obtain a
domain name" [4].
 
best,
   john

  -----------------

Snarky notes:

[1] While there are clearly exceptions, there is considerable
evidence that "Honest and Careful Registrar" is an oxymoron and
even that a complete lack of scruples, or at least aggressive
and deliberate ignorance about registrant credentials, are
encouraged by ICANN policies.  If that be the case, then
authentication methods that ultimately depend on the
identity-quality of domain "purchase" and registration are
effective only to the extent to which an attacker is lacking in
motivation... unless one knows the domain of the relevant
individual and server with some independent certainty (that
notion of independent authentication again) and that the FQDN
string is spoof-proof.

[2] Of course, if the attacker cannot, or isn't willing to
invest the resources to, intercept and capture or divert an
in-transit data stream (or fake DNS records) then I don't quite
understand the threat model that unauthenticated (or very low
quality authentication) encryption protects against.

[3] If someone shows up at a key signing whom I've never seen
before and hands around a passport that says "Republic of Lower
Slobbovia" on the cover and has a picture and name inside,
whether a potential signer knows more about that individual's
identity than "appears to be human, etc.".  Few of us have ever
seen a Lower Slobbovian passport much less know how to
authenticate one.  So, again, authentication and quality of
credentials covers a broad spectrum.  The question isn't
"authentication or no authentication", it is what sort of
credentials are good enough for an intended purpose (and in
context with other methods).

[4] Note too that any sort of credential that draws on the DNS
for authenticity or key integrity and binding works a lot better
for domain-per-individual or domain-per-activity than it does
for domain-per-group-or-enterprise because, to some extent, such
methods depend on one's trusting everyone who is either a
legitimate user of the domain or who can compromise it.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 03 Feb 2014 15:00:47 +0100

* John C Klensin wrote:
>X.509 cert).

You do not need keys or certificates in that scenario.

>the proverbial entity-in-the-middle.

Without entities in the middle, encryption is unnecessary.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 3 Feb 2014 09:05:47 -0500

On Sun, Feb 02, 2014 at 06:44:58PM -0600, Pete Resnick wrote:
> I agree that authentication is irrelevant in this context. But
> that's leads me to agree with Dave on a central point (hence the
> little I-D we've been banging on and submitted to the STRINT folks):
> The problem with PGP and S/MIME is that they require authentication
> in order to start using encryption, and since authentication is both
> irrelevant to this *and* a pain to do...

We should be a bit careful about our terms here.  If we don't care
about authentication at all, one solution is to just do hop-by-hop
diffie hellman (or TLS with completely unchecked certificates).
That's actually pretty easy, and it's not a bad thing to do whether or
not we do anything else, since it makes pervasive monitoring more
expensive by requiring the attacker to forgo passive eavesdropping and
have to do active M-I-T-M attacks.

If instead what we are saying is that we don't really care about
tieing a particular encryption key to a specifically named human
being, but to some other property, then this starts addressing the "do
we really need to have geek-friendly-but-scares-the-civilians PGP key
signing party" problem.  Instead you might want to say, "I don't care
whether this really is Mr. John Doe from Lower Elbonia, but I do want
to know whether this is the same entity who has been corresponding for
the last two months on the wg mailing list --- or is the author of a
particular I-D".

As a specific example, if all you want to do is make sure that someone
really controls the e-mail address named in the PGP key identity, then
you could do an web-automated version of "CAFF" (Certifying Authority
Fire and Forget)[1].

[1] http://manpages.ubuntu.com/manpages/hardy/man1/caff.1.html

So imagine a web service, running on tools.ietf.org, (a) which makes
someone prove that they have control over a specified e-mail address,
by mailing them a URL with a one-time code embedded in it, then (b)
asks them to upload a PGP key, and then (c) it sends back to that
e-mail address their PGP key signed with a registry key --- but the
signature is encrypted so only someone with the private key of the PGP
key can decrypt it.  This basically proves that the submitting entity
has control over both the e-mail address and the private key of the
PGP key that they are requesting be certified.

If this is being done via https, and you trust that the CA for
ietf.org is doing a competent job, and *all* CA's and sub-CA's trusted
by your browser are doing a competent job, then this will basically do
what you want, and it doesn't require people to show up at a PGP
signing party.  The user experience becomes that which is needed when
you sign up for a Google, or Yahoo, or any other web site which
demands that you prove that you have a valid e-mail address.

						- Ted

---

From: t.p. <[email-masked]>
Date: Mon, 3 Feb 2014 10:05:53 +0000

---- Original Message -----
From: "Pete Resnick" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, February 03, 2014 12:44 AM
> address pieces of it, we need to start looking at different sorts of

Quote from the uta charter
"
- Consider, and possibly define, a standard way for an application
client and server to use unauthenticated encryption through TLS when
server and/or client authentication cannot be achieved.
"

Would that fit the bill?

Tom Petch

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Feb 2014 09:32:18 -0500

> diffie hellman (or TLS with completely unchecked certificates).

Yes, we need to decide what the threat model is and what the outcomes we
want to achieve are.

We also have to consider if there really are are downsides to having people
use less than perfect encryption. Because a lot of the reason for email
encryption taking so long seems to me to be people worried about doing it
wrong and making a mess. And that is the reason that PGP exists in the
first place: Phil Z. got tired of waiting for perfect and decided that
'Pretty Good' would be enough.

I see two separate sets of reasons for getting the whole IETF to start
doing secure email

1) We need to get people to start eating the dog food so that they
understand the reasons why the customers still refuse to eat it after 20
years.

2) Everyone who is involved in IETF in a significant degree is a target.
Intelligence services go after people who have the information they want.
And we have more of that than most. And its not just the security area
either. The pervasive intercept capability folks must keep a close eye on
technical changes that would affect their capabilities.

For twenty years now we have been arguing over PGP vs S/MIME. Lets stop
that. Both specifications could do with an upgrade. Lets develop an upgrade
that is a worthy successor to both and provides for full backwards
compatibility or as much backwards compatibility as makes sense for both.
-- 
Website: http://hallambaker.com/

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Feb 2014 10:12:30 -0500

--On Monday, February 03, 2014 09:05 -0500 Theodore Ts'o
<[email-masked]> wrote:

>> that's leads me to agree with Dave on a central point (hence
>> the little I-D we've been banging on and submitted to the
>> STRINT folks): The problem with PGP and S/MIME is that they
>> require authentication in order to start using encryption,
>> and since authentication is both irrelevant to this *and* a
>> pain to do...
> 
> We should be a bit careful about our terms here.  If we don't
> care about authentication at all, one solution is to just do
> hop-by-hop diffie hellman (or TLS with completely unchecked
> certificates). That's actually pretty easy, and it's not a bad
>...
> As a specific example, if all you want to do is make sure that
> someone really controls the e-mail address named in the PGP
> key identity, then you could do an web-automated version of
> "CAFF" (Certifying Authority Fire and Forget)[1].
> 
> So imagine a web service, running on tools.ietf.org, (a) which
> makes someone prove that they have control over a specified
> e-mail address, by mailing them a URL with a one-time code
> embedded in it, then (b) asks them to upload a PGP key, and
> then (c) it sends back to that e-mail address their PGP key
> signed with a registry key --- but the signature is encrypted
> so only someone with the private key of the PGP key can
> decrypt it.  This basically proves that the submitting entity
> has control over both the e-mail address and the private key
> of the PGP key that they are requesting be certified.
> 
> ietf.org is doing a competent job, and *all* CA's and sub-CA's
> trusted by your browser are doing a competent job, then this
> will basically do what you want, and it doesn't require people
> to show up at a PGP signing party.  The user experience
> becomes that which is needed when you sign up for a Google, or
> Yahoo, or any other web site which demands that you prove that
> you have a valid e-mail address.

Right.  Very weak authentication of individual identity but,
given the above assumptions, decent-or-better authentication of
ownership of keys, addresses, and identity-persistence.  Whether
that is good enough depends on one's concerns and attack
scenarios -- for the IETF list, I'd imagine almost no one would
care.  And, of course, the requirement of competence by "*all*
CA's and sub-CA's trusted by your browser" doesn't pass a laugh
test these days unless one is paranoid and geeky enough to edit
browser CA lists down to those one actually has reason to trust.

That is why I think it is worthwhile to tease out what we really
want and need, not say blanket things like "no authentication
needed" as Pete's note seemed to.

     john

---

From: Stephen Kent <[email-masked]>
Date: Mon, 03 Feb 2014 10:28:00 -0500

I think the S/MIME tripe wrapping feature may already provide a way to 
conceal
header info not needed to delivery.

Steve
> 2.  It's unrelated to the parts of such a service that appear to be 
> the major barriers to large-scale use
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Feb 2014 10:31:07 -0500

> browser CA lists down to those one actually has reason to trust.

On another list we have pretty much agreed that we are not interested in
checking government issued ID in an IETF context.

Now there are many contexts where checking government issued IDs or
employment badges or the like makes a lot of sense and Comodo is one of
many CAs that support that type of enterprise need. But it is clear that we
are not in that situation here.

So what validation process is there for me to validate against? All I can
see is checking the email address with some sort of callback loop.

One of the reasons S/MIME has taken so long to take off is that people
built the toll booths before the highway. In a world in which everyone is
sending encrypted emails there are many ways for CAs to make money but we
are not yet in that world.

The place where I think the CA industry is best placed to add most value is
on the relying party side rather than the subject. Email trust
infrastructures will necessarily be complex and there will be a need for
those trust infrastructures to be curated.

Very few users are going to be 'geeky enough' to weed out their CA list but
there are companies that will do that for them. And its not just CA lists,
it is working out what key services are worth bothering with, evaluating
webs of trust and the like.

I think there are banks who would very much like to be able to send their
customers end-to-end encrypted email provided that the usability issues
with current offerings are addressed.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Feb 2014 10:40:46 -0500

I looked at the specifications recently. There is certainly support for
concealing the RFC822 From and To headers and the Subject line. There are
two sets of metadata to consider:

1) The SMTP routing data (RFC821)
2) The Message headers (RFC822)

There are two sets of issues, one is what the specifications say, the other
is what the implementations do.

S/MIME does support concealing the RFC 822 header data because it is not
used in routing. Only the RFC821 data is used for routing. The RFC822
header data is only used by the email client to decide how to respond.

I have successfully routed several SMTP messages with no RFC822 routing
data at all. I plan testing support for 'full wrap' as described in the
specs but not for a while. To give a useful answer would require a look at
each and every email client including older versions.

The problem then is not how to achieve this particular capability in the
specification, it is how to make use of it in a way that does not cause
unpleasant user experiences when people have non-compliant software.

People with Outlook 2007 (say) who are happy with it are unlikely to want
to spend $350 to upgrade so that they don't get mysterious encrypted
messages that don't have sender names or subject lines.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 03 Feb 2014 08:33:23 -0800

On 2/2/2014 4:44 PM, Pete Resnick wrote:
> think we've got the tools in our toolbox already:

I don't know either.  Depending upon the specific service goals, it 
probably is more than 'integration', which is why I harp on 'usability'.

But some service goals well might make for simplified usability demands.

Some other recent postings are also noting that these sorts of issues 
depend heavily on the specific protections that are sought.  Absent very 
specific statements about the nature of PM threats a given technique is 
intended to protect against (and is explicitly /not/ intended to protect 
against), along with some indication of community support for such 
protections and exposures, we are just doing a random walk through 
solution space.  Random walks produce random results.

If end users are a factor in a solution, then the real-world of 
mass-market user constraints is a factor.  There is an extensive body of 
knowledge about such users and any proposal needs to pay attention to 
that body.  A place to start is by excluding all IETF participants from 
examples.  Another place to start is by distinguishing reasonable 
behavioral expectations for configuration-time actions, versus 
creation-time, versus posting-time.  They are massively different 
operating contexts.

So:  Define the exact anti-PM service to be sought, define the actors 
needed to implement, and then get community agreement that it's an 
important goal to work towards.  Then we can discuss whether it's 
integration or usability or...

d/

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 3 Feb 2014 14:03:19 -0500 (EST)

> From: Phillip Hallam-Baker <[email-masked]>

> killer application secure are 1% of the Web benefits, that is a lot of

Unfortunately, "my bank, my doctor, my brokerage" have all implemented
confidential email, but they are horrible webmail systems.  That means
that a considerable amount of the benefit that will be obtainable from
confidential email is already being obtained, making it harder for
proper confidential email to gain acceptance in the market.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 3 Feb 2014 14:02:31 -0500 (EST)

> From: John C Klensin <[email-masked]>

> confidentiality mechanisms, a few questions/suggestions:

The recent news reports that I have seen are that the NSA's pervasive
monitoring focuses on "metatada", "who is talking to whom".  And the
trouble with end-to-end confidentiality mechanisms is that they do not
hide the destination address; indeed they can't.  And it seems to me
that almost no confidentiality systems have been focused on
confidentiality of message destinations.

So I think some thought needs to be put into what can be done to
thwart pervasive monitoring when the information to be concealed is
the identity of the endpoints.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Feb 2014 08:18:27 +1300

On 04/02/2014 03:00, Bjoern Hoehrmann wrote:
...
> Without entities in the middle, encryption is unnecessary.

I'm having difficulty understanding that assertion.Does your
definition of "entity in the middle" include passive wire/fibre taps?

   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Feb 2014 14:37:05 -0500

> definition of "entity in the middle" include passive wire/fibre taps?

There are active attacks and passive attacks.

When we talk about man in the middle attacks we are usually talking about
an active man in the middle who can change traffic.

A passive wire tap is not usually considered to be a 'man in the middle'
attack.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Feb 2014 08:46:09 +1300

> A passive wire tap is not usually considered to be a 'man in the middle'

Agreed, but it was the assertion that without one, encryption
is unnecessary that puzzled me.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 14:46:45 -0500

> proper confidential email to gain acceptance in the market.

Actually it's not being obtained.   These systems work quite poorly, and typically aren't all that secure.   I do not think they are widely used by customers, because their usability is so bad.

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Feb 2014 14:52:10 -0500

--On Monday, February 03, 2014 14:02 -0500 "Dale R. Worley"
<[email-masked]> wrote:

>...
> So I think some thought needs to be put into what can be done
> to thwart pervasive monitoring when the information to be
> concealed is the identity of the endpoints.

I completely agree.  I just think it is a mistake to become so
obsessed with metadata monitoring (what in PSTN land was often
known as "pen registers" that we ignore data confidentiality.
Similarly, I think it would be a mistake to become so concerned
about the Final Ultimate Solution To Confidentiality Problems
that we stop doing what we can to make known, existing, strong
confidentiality from working effectively and/or better.

In the particular case of metadata/ pen register data it is
probably worth remembering that the most common reason for
collecting such data is to figure out which conversations to try
to capture in more depth, i.e., actually intercept and review
content.  Let's not ignore either threat.

    john

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 3 Feb 2014 14:56:25 -0500

> confidentiality of message destinations.

That's what NSA is doing for telephones, and briefly using e-mail
analyzing communications between US preson under their authorities
(or claimed authorities) under section 215 of the Patriot Act.

It would be a mistake to assume this is *all* they are doing.  Indeed,
it's likely that the NSA is actually doing keyword based filtering of
content, for communications that are between non-US persons and where
the endpoints are outside of the US.  This is done under their
authorities granted to them under Executive Order 12003.

Given that the FBI wanted to drop "Carnivore" servers in US data
centers to do this kind of keyword based filtering many years ago,
it's certainly within the capabilities the US Intelligence Community.

So to the extent that non-US persons want the same level of privacy
that apparently US persons have (unless there is some other secret
court order with some other secret law interpretation we're not aware
of which is enabling the FBI to do this kind of snooping, and we just
don't know about it yet), it's not surprising people are interested in
encrypting e-mail bodies.

Encrypting the endpoint identities is a lot more difficult, since you
need to route the information somehow.  There are solutions such as
onion routing, but they ease of use isn't quite there, and I don't
think they currently would scale well if huge numbers of people were
using them.

Certainly hiding the RFC-822 headers, including the subject lines,
inside the encrypted body would certainly be a good start, but of
course that doesn't solve the issue of the SMTP envelop information.

       	    	    	      	    - Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Feb 2014 16:43:40 -0500

On Mon, Feb 3, 2014 at 2:46 PM, Ted Lemon <[email-masked]> wrote:

> Actually it's not being obtained.   These systems work quite poorly, and
> typically aren't all that secure.   I do not think they are widely used by
> customers, because their usability is so bad.
>

They are not secure at present.

But there is considerable money available to make them secure.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 16:59:01 -0500

> But there is considerable money available to make them secure.

Sure, but as long as there is no regulatory pressure to do so and the end-user has to pay for the occasional slip-up, nothing will change.   During that period, the opportunity exists to improve the state of the art in email security.   Should we succeed before the first really big bank security disaster, it is possible that our solution will appear expedient.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Feb 2014 17:21:40 -0500

On Mon, Feb 3, 2014 at 4:59 PM, Ted Lemon <[email-masked]> wrote:

> Sure, but as long as there is no regulatory pressure to do so and the
> end-user has to pay for the occasional slip-up, nothing will change.
> During that period, the opportunity exists to improve the state of the art
> in email security.   Should we succeed before the first really big bank
> security disaster, it is possible that our solution will appear expedient
>

You mean before the London Whale loses $2 billion in rogue trading
losses...

I am just waiting for one of these mega trading losses due to fraud to
cause the likes of a Citi to go under.

At least Alexander had the decency to (eventually) offer his resignation
after the consequences of his incompetence became apparent. The city types
give themselves bonuses. Large ones.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 3 Feb 2014 20:21:21 -0500

It's Executive Order 12333 not 12003, which is quite different.

Also, we have sources that say they do the same bulk collection with credit card purchase transaction metadata (WSJ reported the Thursday of the week last June that began the Snowden disclosures). Although that's not commsec.

Responding to and earlier email on this thread out of order (sorry Theodore), I think devaluing the power of metadata and traffic analysis is a bad path to start down on. Content often has to be further interpreted and in many cases context can be inferred from metadata. Matt Blaze has a great Wired opinion article that makes a number of very good points with respect to what one can learn via metadata. best, Joe

> On Feb 3, 2014, at 14:56, Theodore Ts'o <[email-masked]> wrote:
>

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 04 Feb 2014 14:01:03 +0100

> integration or usability or...

+1, we take for granted that PM is dangerous, but I haven't seen a
convincing explanation of that threat.  I read Matt Blaze's "Phew, NSA
Is Just Collecting Metadata. (You Should Still Worry)" and I was
worried already.  Yet, I'm unable to say why everybody else should be
worried too:  They can work out my private habits and my circles, so what?

Is there risk of contamination, like with AIDS?  Hm... We can argue
that psychological profiles can ease political campaigns, so those who
are entitled to vote have the moral duty to protect their independence
of thought, for the sake of democracy.  That's not a convincing
explanation for most people, though.

Using PGP augments metadata by bringing in a signature and the whole
circle of those who signed it.  Keysigning parties build a kind of
social network, which is transparent to interceptors.

Trust in CAs is not obvious, and easily it ends up adding "spend more"
to the already great "the best technology we have is annoying  and
will require you and your correspondents to learn more, and fuss
more, than you would probably like".

And encrypted messages cannot be checked against viruses.

Ale