Subject: Re: [openpgp] OpenPGP private certification [was: Re: Manifesto - who is the new OpenPGP for?]

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 01 Apr 2015 13:22:51 -0400

On Sat 2015-03-28 15:24:38 -0400, Phillip Hallam-Baker wrote:
> By that I mean fixed in time. I agree that it does not need to be
> public. Only the hash needs to be enrolled.

Normal e-mail addresses are low-entropy, right?  this would suggest that
they're reversible in most cases without a lot of effort (e.g. consider
nsec3-walker, which has similar properties [0]).  how does enrolling
only the hash address the privacy considerations effectively?

     --dkg

[0] http://dnscurve.org/nsec3walker.html

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Apr 2015 13:38:27 -0400

> [0] http://dnscurve.org/nsec3walker.html

I was planning to enroll the hash of the keysigning which would
include the signature at minimum.

If we are doing DSA then it isn't really a problem as the signatures
are non deterministic. You can get into issues with RSA though (but
not in this case).

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 01 Apr 2015 14:19:02 -0400

> include the signature at minimum.

If you log the hash of the keysigning, then how are the logs useful?
the way that you detect misissuance in a log is that you can scan the
log to see if any new certs have been issued over the identity or
identities that you are interested in monitoring.  If the only thing in
the log is the hash of the full cert, how do you know whether that cert
is one you should be concerned about or not?

           --dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Apr 2015 14:56:16 -0400

OK, this is what I am planning to do for PrismProof email.

After trying a number of approaches I have concluded that the best
approach today is to insist that each keypair have exactly one
purpose.

So Alice will always have a personal root key and an intermediate key
signing key and the fingerprint of this PKI is the hash of the keyinfo
block of the personal root. to do key endorsement she will also need a
key endorsement key on each device she wants to use for endorsements.

Alice-Personal-Root -> Key Signing Key -> Key Endorsement Key[s]

[One reason for the no sharing rule for KEKs is that it makes dealing
with a stolen phone etc. much easier]

Each cert in this chain would be enrolled in an append-only
cryptographic log which provides proof that it existed at a particular
point in time. But none of these certs requires an email address.

For various reasons, we probably want these certs to be enrolled in a
transparent log that publishes both the block chain and the input
data. It is not necessary for a log to publish the input values to fix
them in time however.

When Alice endorses Bob, this is not an operation currently supported
by PKIX and so the 'no new ASN.1' rule applies. The endorsement is
probably some sort of JSON structure:

{"name":"Bob",
 "email":"[email-masked]",
  fingerprint":"phb:qweflkqwhjdflkjhasdlkjhasdvlkjhlksajvh",
  "date":"2015-04-01:01:23Z",
  "blind":"askfasjkldhkjashdvkjhsadkjh"}
<...Signature data...>

This is of course simply another form of certificate but it is a very
different type of cert so its best to use a different term. Alice is
not going to commit to managing the endorsement lifecycle.

The property we want to get from enrolling the endorsement in a log is
to fix it in time. So we enroll the hash in the log rather than the
endorsement itself.

The value "blind" is a random value that leaks Alice's RNG to the
NSA^h^h^h^h^h^h^h^h prevents dictionary attacks.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 01 Apr 2015 16:04:13 -0400

> to fix it in time. So we enroll the hash in the log rather than the

It sounds to me like what you're aiming for with the log to make a
first-come, first-served arrangement, maybe as a way to distinguish the
"correct" original key from some latecomer spoof that tries to usurp it.
Is that correct?  (this is quite different from the goals of CT, as far
as i understand it)

If FCFS is your goal, how does a user of this scheme considering
multiple keys for e-mail address [email-masked] distinguish the
inevitable legitimate transitions from the would-be usurper?

Some examples of legitimate transitions:

 * Alice loses her personal root key due to fire/theft/flood/whatever

 * Example Corp. closes down, the example.com domain name goes up for
   sale, and the new owner is a different Alice.

(this is getting pretty far afield of openpgp at this point, i think, so
i'm happy to take this discusion someplace else (therightkey?) if you
prefer).

   --dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Apr 2015 16:12:16 -0400

> i'm happy to take this discusion someplace else (therightkey?) if you

Yeah we could go to RightKey.

But I am not arguing for first com first served. I am arguing that the
age of an endorsement is significant. An attacker can easily set up an
endorsement cartel with 100 people signing each other's keys. But they
can't backdate the endorsements to ten years before they decided they
needed them.

---

From: Derek Atkins <[email-masked]>
Date: Thu, 02 Apr 2015 10:29:16 -0400

> public. Only the hash needs to be enrolled.

Unfortunately it doesn't matter.  As soon as you require any kind of
"enrollment" the system fails.  Period.  This was (and still is, IMHO)
the major issue with X509/SMIME -- My mother would need to jump through
hoops that she doesn't understand how to jump through in order to get
set up in the system.  I.e., the system doesn't work until the user gets
blessed by some CA.

This is IMHO the power of the OpenPGP model -- generate and go.  From a
UI/UX perspective the system asks for some information (which
technically it already has when you create your email account) and it
generates a key pair for you.  Maybe it uploads it to a keyserver (which
I suppose some could consider "enrollment", but it's a far cry from X509
enrollment requirement).

>From this point on the OpenPGP user can encrypt messages to other people
and get encrypted messages to them.  The can choose to get their key
signed by others (or not).  They could get it signed from their
enterprise (if they are in a corporate environment -- my mother
certainly is not).  But the key (pun intended) is that the system works
without any certifications.

>From a usability perspective this is the model I would want to see.  I
honestly don't care if the actual messages are CMS or 4880 (although I
have a large disdain for all things ASN1).

So please, for all things sacred, let's not require any kind of
"enrollment" for the system to operate.

Now, if we want to talk about enrollment for "key lookup" properties, of
(non-required) certifications, or anything like that ... I'm all ears.
But it should not be a pre-requisite for a user to get up and running.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Brian Sniffen <[email-masked]>
Date: Thu, 02 Apr 2015 11:42:23 -0400

> can't backdate the endorsements to ten years before they decided they

I don't expect to understand most of the hashes in a log of hashed
signatures.  I wonder how many cloned subsets would be buried in case
they're later needed, and what can be done about that.  The best I can
think of is a transparency log---to not hash those. Big public signers
should offer such logs.  Private citizens signing each others keys
probably won't, but it's still valuable to have a standard format for
non-public endorsements.

Presumably keys should be able to carry a note indicating that
keysignatures should only be trusted if in a log.

-Brian

-- 
Brian Sniffen
"I reserve the right to evolve my views, and state that views I previously
 expressed may have been somewhere along the spectrum from insufficiently
 nuanced through ill-informed to dead wrong."

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Apr 2015 12:09:44 -0400

> I suppose some could consider "enrollment", but it's a far cry from X509

Since the key servers won't allow me to revoke the cert for the
private key I have no control over, I think that it would be more
accurate to say that rather than having no enrollment mechanism, there
is a broken one.

I am not proposing use of X.509 here. In fact I think it is quite
clear that CA issue and peer-peer endorsement have very different
requirements and expectations.

My point is that both can be greatly strengthened by enrolling the
assertions in an append-only log.

I would not suggest PKIX or even ACME to do this. But any Web service
to support this approach should certainly follow the ACME style etc.

> without any certifications.

Which is exactly what I do in PrismProof for S/MIME. Enrollment is not
only optional, it is not implemented yet (I got halfway before ACME
hit and now I am redoing some stuff in the guts).

All I need to send an encrypted mail is

* The SMTP address to send it to
* Either
  * The public key and encryption options
  * A fingerprint to resolve authenticate the above

> have a large disdain for all things ASN1).

I hate ASN1 just as much as the next guy.

I do not care what format the messages are in. All I care about is who
we can reach with them.

There are a billion+ clients in existence with S/MIME built in. Every
email client has to implement TLS these days to secure POP/IMAP/SUBMIT
communications and CMS comes with practically every TLS library.

If there is a message formatting option that lets us reach those
billion+ clients with an OpenPGP message without compromising the
trust model or anything else then lets take it.

I would not try to change the 4880 format but we could probably
document it more rigorously and remove options that are not needed.

The focus for OpenPGPvnext should be to eliminate the cruft while
enabling use of as much legacy infrastructure as possible. AFTER that
is done we can consider how to design a secure messaging protocol that
meets every communication need. Such a protocol will almost certainly
be based on JSON with a minimal extension to support binary blobs and
text blobs.

> "enrollment" for the system to operate.

I certainly don't want an enrollment requirement for making the system operate.

> But it should not be a pre-requisite for a user to get up and running.

Absolutely.

I am not actually a fan of using the cloud as a crutch to solve every
UI issue. But there are a few problems that it is a really big help
on.

The analogy I would point to is the Web. One of the main reasons the
Web caught on was that all you needed to do to get up and running was
to download the server and run it. It didn't even need administrator
privileges to run on port 8000.

Today, anyone who wants to can set up their own Web server and have
complete control. But the simplest approach for most folk is to have
that done for them by a hosting provider.

There are three functions where I see an advantage to the cloud:

1) Notarization (e.g. CT like things)
2) Discovery (How does Bob find Alice's key)
3) Escrow (Storing encrypted private key in the cloud)

All three of these functions are optional. The only reason to do
enrollment is to support these functions. So if you don't want any of
them or you are planning to do some yourself then you don't need
enrollment. The casual first time user is probably best advised to
make use of all three at the start (yes even the third).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Apr 2015 12:19:08 -0400

> probably won't, but it's still valuable to have a standard format for

It is still a hard problem. But using the log turns it from a hard
problem with an infinite number of possible endorsements to a closed
problem with a finite set of endorsements.

Closing the problem also means raising the cost of exposure and forces
the operator to think very carefully before each action. There is also
a maintenance cost if you are doing this on Facebook etc.

What I would start off doing is looking at the time span over which
the endorsements in a ring were added. An organic web of trust will be
established over a period of years. Facebook and Twitter have got a
lot better at spotting fake cartels over the years.

> keysignatures should only be trusted if in a log.

I don't see that, it is a relying party consideration.

---

From: ianG <[email-masked]>
Date: Thu, 02 Apr 2015 18:55:51 +0100

On 26/03/2015 03:56 am, Phillip Hallam-Baker wrote:
> On Wed, Mar 25, 2015 at 7:44 PM, Tim Bray <[email-masked]> wrote:
>> You guys are taking it as axiomatic that a high-quality UX can't be provided
>> for users of OpenPGP.  Used OpenKeychain recently? Not quite there yet, but
>> I think your axiom is looking a little shaky.
>
> Certainly not me.

That's a very important observation.  I don't take it as axiomatic, I 
take it as somewhere between very hard and the wrong question.

Almost the whole problem comes down to time & knowledge.  As I never 
tire of saying, what we knew in 1992 is no longer state of the art; 
we've moved on since then:

Messaging is no longer the same:  we need chat, voice & video, and these 
are challenging in formats, patterns and networking, but also open up 
possibilities for authentication.  Including Tom Ritter's challenging 
post.  PGP was designed for cut&paste email, that's not only the least 
interesting thing, it's also an older generation thing which might not 
be worth protecting at all in 20 years.  With a nod to PHB's approach of 
toughest first.

Storage has changed:  we no longer consider a message over the wire as 
the same thing as a message at rest on disk.  We do/don't keep video 
chat, we do/don't take naughty snaps using screen shots.  We do/don't 
share huge files (movies) for which OpenPGP is entirely unsuited because 
it assumes everything is a datagram, and 16G datagrams aren't supported 
by any other software.

Evidence has changed:  we do/don't keep transcripts around for evidence. 
  We do/don't think of digsigs as human signatures.  We do/don't worry 
about removal of files.  We do/don't consider the wire to be a threat 
and we do/don't consider our counterparty to be a threat.

WoTs are no longer the same:  we now have social networks, which love 
them or hate them, have raised the bar so substantially that the PGP's 
communal notions of WoT are vestigial.

Value has changed:  we now have serious and competing payment systems, 
all of whom want to integrate with all aspects of life.

Computing & networking has changed:  we can no longer rely on our own 
trusted platform.  We can't rely on "one platform" and we can't rely on 
ownership, eg BYOD.   Instead it's all mobile, and we're at the mercy of 
what we get given, and what they bring.  Small factors, always present, 
always online, always travelling.

Our models of shared computing are changing:  As Derik mentioned, PGP 
started in a keys-in-pocket age, but we also had client-server + 
enrollment with S/MIME.  Then there's social networking, and now there's 
cloud.  Popular is blockchain, various groups are trying to put 
'identity' onto a shared context, which also answers part of Derik's 
implied permissionless requirement.

So, what do we want to use PGP for, and is that still good?

In 1992, almost everything about securely using the Internet could be 
answered by saying "use PGP".  In 2015, almost nothing about security 
using the Internet can be answered by "use PGP" at least the old one.

iang

> PrismProof email makes S/MIME completely frictionless in use by
> essentially grafting the PGP fingerprint trust model onto S/MIME.
>
>
> I think the idea that we are going to get anywhere by pointing to the
> faults in opposing systems is also flawed.
>
> S/MIME and PGP have both suffered from lousy usability because the
> original trust models simply don't work. X.509 is fine as a
> certificate format, but there is no key discovery infrastructure until
> deployment of X.500 is complete. Web of Trust is a fine academic
> theory but it is not how OpenPGP is really used in the real world.
>
> The lesson here that I draw is to look at how people are actually
> using OpenPGP in practice and work out ways to apply the same approach
> to other similar problems.
>
>
> I do use one trick I borrowed from TimBL, take all the information you
> need to establish a connection and smoosh it together in one
> identifier:
>
> AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB?[email-masked]
>
>
> But more recently, I have been playing about with games similar to .onion:
>
> [email-masked]
> http://example.com._AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB/
>
>
> OK, so what is going on here? Well we have a fingerprint as the
> rightmost (i.e. most important) item in the DNS identifier. Which
> means 'require a signed security policy describing how to interact
> with the identifier to the left.'
>
> So if you want to send email to [email-masked], do so under a
> security policy that is signed under a key with the fingerprint
> AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB.
>
>
> That security policy could say something like 'use PGP encryption to this key'.
>
> One of the things OpenPGP proves is that we can quite easily build an
> infrastructure that maps from a fingerprint to a security policy. But
> one of the major changes since BaL and David and co put the MIT PGP
> server together, the Harber-Stornetta patents have expired and we now
> have better options like TRANS (or the BitCoin blockchain without the
> need to wade through treacle).
>
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Werner Koch <[email-masked]>
Date: Wed, 08 Apr 2015 12:53:28 +0200

> private key I have no control over, I think that it would be more

They allow that but you need to have a key prepared for this:

 5.2.3.15.  Revocation Key

   (1 octet of class, 1 octet of public-key algorithm ID, 20 octets of
   fingerprint)

   Authorizes the specified key to issue revocation signatures for this
   key.  Class octet must have bit 0x80 set.  If the bit 0x40 is set,
   then this means that the revocation information is sensitive.  Other
   bits are for future expansion to other kinds of authorizations.  This
   is found on a self-signature.

("gpg --edit-key, addrevoker" to set such a key and "gpg --desig-revoke"
 to issue a revocation)

Shalom-Salam,

   Werner

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 09:05:44 -0400

> ("gpg --edit-key, addrevoker" to set such a key and "gpg --desig-revoke"

If I could remember my passphrase then I would not need to revoke.

My point here is that if we want to get a billion people using
encrypted mail then it has to offer iPhone class usability, not OK for
1990s usability.

There are plenty of ways that the scheme could be fixed. Since key
server enrollment can be made automatic, it would be pretty easy to
renew the enrollment once every n months and discard keys that have
not been renewed for 5 years or for more than a year if there is a
replacement key.

Having the key servers continue to regurgitate false or stale data
forever because there is no way to stop them does not seem like an
acceptable plan to me.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 08 Apr 2015 15:11:35 +0200

> If I could remember my passphrase then I would not need to revoke.
Which is why people are ever since suggested to create their revocation
when the create their key.

> encrypted mail then it has to offer iPhone class usability, not OK for
Crypto is not an iPhone.
Just accept that you can't make a system securely usable if people
aren't willing to learn how it works and put some effort into it.

> Since key
Removing a key (and its associated information like revocations or other
signatures) from the keyservers is generally a break of security, as it
allows for blocking or similar attacks.
And attacker could make a valid key removed just by blocking keys that
haven't been "renewed".

Chris.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 09:23:35 -0400

>> encrypted mail then it has to offer iPhone class usability, not OK for

Mine is.

Mine has no impact at all unless the user is asking 'is this secure'.
I have code that shows this is possible and practical.

> aren't willing to learn how it works and put some effort into it.

I don't accept that because it isn't true.

> And attacker could make a valid key removed just by blocking keys that

And what is to stop someone maliciously loading up a broken key or an
entirely fraudulent key?

I don't think that you can make a good case for circulating bad data
in case it might be good.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 08 Apr 2015 15:33:48 +0200

> Mine is.
Believing that you're secure with a proprietary driven system, from a
company which is known to have worked with mass surveillance
organisation (and if it's just because they were forced so by law), is
naive - at best.

> And what is to stop someone maliciously loading up a broken key or an
Nothing, but neither would these be trusted nor has it anything to do
with the security breaches that arise from removing data from the
keyservers.

> in case it might be good.
A key and associated information doesn't become "bad" just because the
user didn't "renew" it.
We have explicit mechanisms for users to mark their keys as no longer be
usable, either by revocation signatures or by giving them an expiration
date. Both methods let the decision in the hand of the user and don't
place it into the hand of potentially evil other parties.

And if with "bad data" you mean corrupted keys in the sense of broken
uploads or that like, then this is obviously something different.
Such key would immediately be ruled out and not because someone decided
that it suddenly doesn't match some criteria anymore.

Regardless of how you put it, removal of valid keys (valid in the sense
of "conforming to the OpenPGP format" is a break of security.

C.

---

From: Werner Koch <[email-masked]>
Date: Wed, 08 Apr 2015 15:35:09 +0200

> encrypted mail then it has to offer iPhone class usability, not OK for

If that is the goal you only need to care about 140 character messages
or other useless status messages ;-).

Actually I prefer 1990s use of mail instead of todays 50% of mails are
going through Compuserve^WGmail.  But yeah, I am on a lost position with
that.

> renew the enrollment once every n months and discard keys that have

It is about mail.  Mail addresses are defined by the DNS.  Bind the keys
to the DNS and your are done.  This needs support from the mail
providers, though.

I doubt that we will be able to deploy a large, encrypted, anonymous,
and decentralized mail network unless we can build upon a transport
layer to solve the basic problems of todays Internet.  For now we need
the help of some central services to get things going.

> forever because there is no way to stop them does not seem like an

Think of signature verification.  It should work even after a mail/key
association has been disolved for example after a provider change.  I
agree that this is onluy a problem for a smaller group but this is
something a keyserver network can be useful even after the migration of
the public key store from keyserver to more controlled service (DNS,
Web, whatever).  Deleting keys from the keyservers is thus not going to
work.

Shalom-Salam,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Apr 2015 09:43:57 -0400

> encrypted mail then it has to offer iPhone class usability, not OK for

Werner's point is that you can set up anyone to be your designated
revoker.  It doesn't have to be *YOUR* key, you can designate your
mother, your wife, your child, or even your, gasp, CA!! to be a
designated revoker.

> not been renewed for 5 years or for more than a year if there is a

That's not the same thing as actually *revoking* the key.

> forever because there is no way to stop them does not seem like an

This is also a reasonable goal, but completely separate from revoking
your key.  Revocation is (as you well know) a cryptographic assertion,
not a "database" concept.  Indeed, you would want to continue to
distribute a revoked key so that people who have it cached locally will
update with the revocation data!

-derek

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 10:00:14 -0400

> organisation (and if it's just because they were forced so by law), is

All the code is up on sourceforge and always has been.

http://prismproof.org/

As for working with folk involved in mass surveillance, that is
inevitable in our industry. All of us have, yourself included.

CERN has always been a prime target of intelligence agencies. Putting
all the boffins in one place so they could be watched was one of the
primary reasons it was funded in the first place.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 10:15:41 -0400

> to the DNS and your are done.  This needs support from the mail

I really don't like the use of the DNS for any scheme requiring more
than host level granularity. We have tried to put user email addresses
in the DNS from the very start [RFC1035]. It has never worked.

Personally, I believe that owning your personal DNS name is as
important for security as having a keypair. I have a huge part of my
brand invested in [email-masked] which I don't own. Which is why I
switched to [email-masked] for ietf work. But I have yet to win
that argument.

I really don't like having ICANN as my root CA either. DNSSEC is a
monolithic, single rooted scheme which I don't consider very
trustworthy because of that.

We do need trust hierarchies for key management. But each individual
should be the root of their personal hierarchy.

> Web, whatever).  Deleting keys from the keyservers is thus not going to

I don't think anyone has signature validation done right today. All
signatures are broken unless they are enrolled in an append-only log.
To verify a signature, you need to go back in time to the point where
the signature was created and check the signature in that time
context.

This implies that all the cryptographic credentials should be enrolled
as well. Which is something I am working on right now. But in JSON,
not ASN.1.

The expiry of the hash chain patent is an opportunity to do
interesting stuff that was encumbered before.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 08 Apr 2015 19:55:52 +0200

> All the code is up on sourceforge and always has been.
So? Gnupg is available as well, but this doesn't make it necessarily
secure to use it under a closed OS, cause it's the later who has
ultimately all control.

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 08 Apr 2015 20:05:05 +0200

On Wed, 2015-04-08 at 10:15 -0400, Phillip Hallam-Baker wrote: 
> important for security as having a keypair.
Why should it give you any security?

> I have a huge part of my
It only gives you that some company cannot easily take away your mail
address, but OTOH it's probably an illusion to believe that your own
domain name protects you much more from this.

See cases like the German person called "Shell", who had shell.de and
guess who has it now.

> trustworthy because of that.
Sure, it has similar problems like the X.509 PKI, just on a less extreme
scale.
But no one should try to impose a strict hierarchical trust model on
OpenPGP anyway. So I don't think it's a particularly good idea to
somehow combine OpenPGP with DNS/DNSSEC/DANE.

If at all that would mostly only interesting for securing TOFU like
systems at least a tiny bit - but OTOH, we shouldn't follow TOFU, it's
basically a big lie as I pointed out in a recent lengthy thread on one
of the gnupg mailing lists.

> should be the root of their personal hierarchy.
+1

> the signature was created and check the signature in that time
I don't get the point here. At least it doesn't sound like anything in
the responsibility of the crypto system, rather something for higher
level programs.

Cheers,
Chris.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 14:29:13 -0400

> Why should it give you any security?

Same reason that backing up your files is the number one security
priority: security means being able to assess and control risks to
your assets. Confidentiality is only one concern and one that is
fairly low down. Integrity is almost always more important.

If I invest in [email-masked] then I am making myself vulnerable to
a change of policy. I have little choice but to pay if they decide to
start charging $50/month.

> See cases like the German person called "Shell", who had shell.de and

Which is one reason I don't trust ICANN's vision of DNSSEC.

But still, security is risk control and not risk elimination -
something I have been saying for over 20 years now.

> Sure, it has similar problems like the X.509 PKI, just on a less extreme

If trades one set of problems for another.

> somehow combine OpenPGP with DNS/DNSSEC/DANE.

I think there are ways to combine PGP ideas with DNS and DNSSEC in a
useful manner, DANE is not one of them.

The approach I have been using most recently is an extension of the
.onion idea. But instead of making a key fingerprint a subdomain, I
make it the root.

So example.com.<fingerprint> becomes an assertion 'the names in
example.com as controlled by a valid, current security policy signed
by  a key matching <fingerprint>.

Now that is an approach I can tie servers to in admin files.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 08 Apr 2015 20:54:42 +0200

> fairly low down. Integrity is almost always more important.
I don't think that either you or me can decide which of the aspects of
"data security" is most important to a user.
It completely depends on the usage scenario and for some integrity may
be actually less important.

But in terms of our discussions here we probably mostly deal with
confidentiality, integrity and authenticity.
And I can't see how a own domain name helps here.

> start charging $50/month.
Sure, but it doesn't improve your confidentiality, integrity and authenticity.
Just make a new UID with another address, publish it, bon.

> Which is one reason I don't trust ICANN's vision of DNSSEC.
Well but that has happened before DNSSEC, it's more a problem of DNS
itself or rather of courts being able to rule about the cyberspace.

> If trades one set of problems for another.
Which problems would it have that X.509 PKI wouldn't have?

> by  a key matching <fingerprint>.
Uhm that probably only works when you chain als signatures of the
respective domain (i.e. NSEC instead of NSEC3), right?

But to me this isn't a integration of DNS into OpenPGP, like in the
sense of using DNS to implement a certain trust model (yes Werner, trust
models are not part of OpenPGP ;-P)
It's vice versa an integration of OpenPGP into DNS,... which is IMHO
again totally fine (at least per se and form the OpenPGP PoV).

> Now that is an approach I can tie servers to in admin files.
AFAIU, you basically just tried to secure your zones via DNSSEC and
OpenPGP, right?
I think that approach is unnecessarily complex, since AFAIU it requires
to fully walk through the zone.
Why don't you just use the openpgp key to sign the DNSKEY RRs (+put the
result in some special RR) and validate that in your resolver before
making any further use of DNSSEC?
Of course, for that being really secure, you'd need to tell your
resolver which domains he should expect to be signed that way, just
relying on the presence of the RR that holds the signature is obviously
not enough (blocking attacks)... and relying on DNSSEC for that
obviously defeats the purpose.
Signatures must obviously also use expiration times.

Also, the method of just adding the fingerprint as an indicator smells
very strong like "replay and downgrade attacks".

Cheers,
Chris.

---

From: Werner Koch <[email-masked]>
Date: Fri, 10 Apr 2015 16:02:35 +0200

> important for security as having a keypair. I have a huge part of my

Although I agree with you, it will not work for the billion users we are
aiming for.

> should be the root of their personal hierarchy.

GNUnet's GNS is what you want.

Shalom-Salam,

   Werner

---

From: ianG <[email-masked]>
Date: Fri, 10 Apr 2015 18:05:57 +0100

> trust model or anything else then lets take it.

Personally I think this is the wrong blockage.  Yes, I recognise that 
the existence of that code inside those 1bn+ clients is potentially 
valuable.

But in practice it is not the key blockage, not even close to being a 
relevant issue.

IMHO the key blockage is politics / commercial control within the 
vendors over the "trust model".  In order to get those clients to open 
up, Mozo and Microsoft need to be incentivised to go in a different 
direction.

In practice this is a much bigger barrier.  As a historical observation, 
there is always a steady queue of hopefuls asking Mozilla to implement 
TOFU & pinning trust models within x.509 products for which *all the 
code is present* but they won't go there.  These hopefuls have all gone 
off depressed and angry, mostly because they never understood that 
Mozilla is a commercial project at that level, and has bought into the 
CA model 100%.

It is for this reason I'm actually very happy that Yahoo and Google are 
doing e2e pgp in their web mail stuff.  The fact that we all know the 
'hushmail' attack is .. unimportant in the scheme of things.  What's 
important is deployment, not perfection in security models.

(all very much IMO, YMMV)

iang

---

From: ianG <[email-masked]>
Date: Fri, 10 Apr 2015 18:24:59 +0100

> organisation (and if it's just because they were forced so by law), is

No, it's security modelling.  It all depends on what the business model 
is, which defines the threats that one has to deal with.  There are 
plenty of people out there that don't care about the mass surveillance 
and there are plenty of people in here who do care about it.  The reason 
that people out there don't care about mass surveillance is because they 
(a) don't see the harm or (b) have bigger harms to worry about.

Sometimes valid reasons, sometimes not.

We have to remember that the old CIA was something that was taught to us 
back in the 1990s out of military models.  E.g., it made sense to 
consider the MITM as a big commsec threat when our only experience was 
MITMs in aggressive military actions -- armies against armies.  But the 
Internet was different, we had different threat actors, different values 
under protection, and different incentives.

There are probably more people out there that don't want authentication 
than do, or more precisely they want nymity.  Canonically, recall all 
the people (eg) Manning who were caught over the net, and had recorded 
chat sessions used as evidence against.  Having unattributable, 
untraceable content is actually a goal for many.

And things like twitter show how confidentiality isn't really the thing, 
but they still put everything over the HTTPS so that at least the 
passive surveillance is turned into active surveillance.

etc etc.  Your enemy may be the NSA.  But for most people most of the 
time, it's others:  aggressive ex-spouses, parents who spy, business 
partners stealing money, teenagers getting into trouble with photos, etc 
etc.

iang

ps; And to echo Phil, my crypto is iPhone too - end-to-end secure 
payments systems.  'cept, Java only runs on Android ;)

---

From: ianG <[email-masked]>
Date: Sat, 11 Apr 2015 17:14:48 +0100

> approach today is to insist that each keypair have exactly one

Concur.

> Alice-Personal-Root -> Key Signing Key -> Key Endorsement Key[s]

OK.  (at least, it mirrors what I do.)

> with a stolen phone etc. much easier]

By that you mean, one KEK per device, not the common proxy SSL device 
rule of one cert shared across all.  OK, agreed if so.

However I'm not sure you'll hit the mark on the stolen phone.  Much of 
the world only has a phone, so it also has to deal with the full 
hierarchy.  A more comprehensive solution is needed.  In my work, I 
duplicate the phone's (encrypted) db onto server (cloud) and then try to 
recover that and get her up and going when Alice loses her phone.  But I 
freely admit it is flawed as it is weakening the entire security to the 
level of her password/pin, in some shared or non-shared form, and 
relying on a bunch of assumptions that for anyone but a security geek 
look exceedingly mushy.

> data. It is not necessary for a log to publish the input values to fix

You're saying that the KEKs are published in their entirety, but they do 
not include any sensitive information.  Just a signing hash that points 
back up to the cert hierarchy.

So what is your motive for timestamping / proof of existence here - to 
stop people creating sybils?

> different type of cert so its best to use a different term.

Yes.  But it in itself is also quite defined.  So, in the above, Alice 
endorses Bob lacks any sense of "for what?"  Do we need a different 
endorsement for each "what" or are we looking for a general endorsement 
and a "what policy" or a "what statement" ?

> Alice is

Agreed.  But she is going to be pissed when it breaks on her.

> to fix it in time. So we enroll the hash in the log rather than the

So, a log can be used for:  fixing in time, publishing, proof of 
existence without time, proof of revocation, ... possibly other things. 
  Do you have a sense that we know enough about the endorsement to be 
able to tie down those benefits?

Reason I ask is this:  in my work, the endorsements are shared amongst a 
group, but not further.  They are replaceable.  And they are analisable. 
  So they aren't really private but they aren't published.  (They are 
also wrapped up in a legal context.)

My question then comes down to finding the low layer endorsement brick 
that allows me to build my castle of trust.

> NSA^h^h^h^h^h^h^h^h prevents dictionary attacks.

:)

iang

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Apr 2015 14:51:06 -0400

> By that you mean, one KEK per device, not the common proxy SSL device rule
> of one cert shared across all.  OK, agreed if so.
>
> However I'm not sure you'll hit the mark on the stolen phone.  Much of the
> world only has a phone, so it also has to deal with the full hierarchy.  A
> more comprehensive solution is needed.  In my work, I duplicate the phone's
> (encrypted) db onto server (cloud) and then try to recover that and get her
> up and going when Alice loses her phone.  But I freely admit it is flawed as
> it is weakening the entire security to the level of her password/pin, in
> some shared or non-shared form, and relying on a bunch of assumptions that
> for anyone but a security geek look exceedingly mushy.

I am doing the same.

While I agree that this might look like a lot of unnecessary keys for
people with only one device, it is much simpler to give everyone the
full hierarchy than deal with 'luxury' and 'economy' versions.

Devices break. Devices have a limited life. Thinking poor people have
fewer devices than rich people is probably mistaken.

> You're saying that the KEKs are published in their entirety, but they do not
> include any sensitive information.  Just a signing hash that points back up
> to the cert hierarchy.
>
> So what is your motive for timestamping / proof of existence here - to stop
> people creating sybils?

If someone presents you with a key endorsement for a Barry Obama email
at Harvard.edu that could have been created five minutes ago it is
worthless. If you have the same endorsement and can prove that it was
published twenty years ago when he was a student it is worth a great
deal more.

Enrolling endorsements in notary logs has a dramatic impact on the
trust model. The cost of forging that endorsement goes from zero to
essentially infinity at the time it is created. That is real power.

> endorsement for each "what" or are we looking for a general endorsement and
> a "what policy" or a "what statement" ?

Yes, understanding that is useful. And so is binding to process. An
endorsement created by an iphone app and enrolled is a particular
quantity, etc.

> So, a log can be used for:  fixing in time, publishing, proof of existence
> without time, proof of revocation, ... possibly other things.  Do you have a
> sense that we know enough about the endorsement to be able to tie down those
> benefits?

The internet draft I wrote describes some of the benefits in terms of
a timed work factor model.

> group, but not further.  They are replaceable.  And they are analisable.  So
> they aren't really private but they aren't published.  (They are also
> wrapped up in a legal context.)
>
> My question then comes down to finding the low layer endorsement brick that
> allows me to build my castle of trust.

Trying to work with casual endorsements alone is a mistake. There is
no grounding at any point. The value of endorsements quickly dwindles
to zero through generation loss.

If there are a just a few endorsements that are tied to a specific
process (i.e. a CA process) then the work factor becomes stable and
objective.

---

From: Ben McGinnes <[email-masked]>
Date: Wed, 15 Apr 2015 19:13:36 +1000

> or other useless status messages ;-).

Drop SMS in favour of MMS and use that to sent ASCII-armoured OpenPGP
messages.  TextSecure?  Yes *and* no ...

> going through Compuserve^WGmail.  But yeah, I am on a lost position with

Oh god ... that's so accurate (at least they're not AOL, though).

> It is about mail.  Mail addresses are defined by the DNS.  Bind the
> keys to the DNS and your are done.  This needs support from the mail
> providers, though.

TXT records, just as was done with SPF before it was adopted as a standard.

Though it would be nice to be able to set:

IN     PGPKEY	"ben:  0x321E4E2373590E5D"
IN     PGPFPR	"ben:  DB47 24E6 FA42 86C9 2B4E  55C4 321E 4E23 7359 0E5D"
IN     PGP	"Catchall:  <key id> "

Get around that with TXT records and prepend the response value with
what you'd eventually want adopted as DNS records.

> the help of some central services to get things going.

Erm, there was a post to gnupg-users last month which proposes a
method of doing something which is very close to that.  The
confidantmail.org thing (which already proposes using DNS TXT records
for key ID listings).  It's pseudonymous rather than anonymous, but
the only pseudonym required is the key ID/fingerprint of any given
key.  Everything else is arbitrarily assigned (and uses freeform
UIDs).

Actually, Phillip, that thing is probably right up your alley given
some of the other SMTP related posts around here, you should
definitely go and play with it.

> association has been disolved for example after a provider change.

Right and all you need to do to prove the current key ID associated
with an email address is to use the PGP Global Directory Verification
Key.  The stale data won't gain signatures like that.  The Hushmail
keyserver will provide a similar verification (and limits one key ID
per UID email address, but does not limit the number of UIDs
associated with a key ID).

> I agree that this is onluy a problem for a smaller group but this is
> something a keyserver network can be useful even after the migration
> of the public key store from keyserver to more controlled service
> (DNS, Web, whatever).  Deleting keys from the keyservers is thus not
> going to work.

Besides, even if you did delete a key (and even if it was your own),
there's very little preventing someone else re-uploading it.  This is
clearly illustrated by the signature on my key made last June by key
ID 0x46406269AA2F6FBE.  The exception bing the Hushmail key server,
which throws a fit if you want to update to a new key (it can only be
done by contacting them directly and getting it changed manually, but
that's the only way to get Hush users to be able to natively encrypt
to you or verify your signatures).

Anyway, we've all made the error of forgetting a passphrase and being
unable to revoke a key when we might want to.  It's what taught us to
remember the current passphrases (why do you think I got into the
habit of signing by default, initially it was so I'd remember the
passphrase and now it's just a good habit).  As for the keys which
taught me that lesson, well, I eventually did remember the passphrase
... a mere fourteen and a half (14.5) years later, so they got to sign
the current key before being revoked.

Yes, there are some annoyances, but really those are a small price to
pay to prevent having your key arbitrarily removed by a particularly
determined adversary.  Imagine, for a moment, if Glenn Greenwald and
Laura Poitras had had their keys arbitrarily removed from all
keyservers back in 2011 in response to certain WikiLeaks publications
and articles ... or worse, replaced.  At the very least the
CitizenFour documentary wouldn't've happened and at worst, well, we'd
all still be making oblique references to ECHELON instead of PRISM.
It'd be like living in a world where NCIS dictated reality and while
Mark Harmon portrays droll, dry humour well enough; that is nowhere
near enough to justify an existence like *that*.  Not to mention
accepting NIST recommendations at face value ...

See, there's a scary side to everything.  You're welcome.  ;)

Regards,
Ben