Subject: Re: [dane] Summary of IETF LC for draft-ietf-dane-openpgpkey

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 17 Sep 2015 14:09:11 -0400

> On Sep 17, 2015, at 5:26 AM, John C Klensin <[email-masked]> wrote:
> 
> The document seems to say that I should not trust a key found by
> this method just because of where I find it.  That is entirely
> consistent with other PGP documents and existing keyservers.  I
> should, instead, rely on web of trust relationships, e.g.,
> signatures on the particular key.

OPENPGP is a data format, WoT is one way to employ that format to
exchange messages.   It is not a *required* way to use OPENPGP.
In particular, if a user elects to configure an MUA to use DNSSEC
as a trusted introducer, so as to be able to increase privacy
of messaging beyond his immediate social circle, that's a fine
choice.  Think of it as "opportunistic PGP".  It's what you
do when you'd have otherwise sent the email in the clear anyway.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 21 Sep 2015 17:21:09 -0000

>exchange messages.   It is not a *required* way to use OPENPGP.

Sure, but it's the way that everyone has used PGP for 20 years,
and it's the security model that everyone I know expects when they
use PGP keys.

This draft uses a model in which the key is bound to a mailbox, not
any stronger identity, and you have to trust that the domain's
management fairly represents its users rather than e.g., publishing
MITM keys that it controls.  That's not a ridiculous model, but if
that's the model, the draft and draft-ietf-dane-openpgpkey-usage need
to say so.  At this point, neither does.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Sep 2015 15:14:36 -0400 (EDT)

> and it's the security model that everyone I know expects when they

Actually, nmost people I know never use the WoT. They only use keys
obtained directly from the person they want to exchange encrypted email
with.

> This draft uses a model in which the key is bound to a mailbox

openpgp keys are bound to ID's, which can ultimately end up in a
mailbox but is not required to do so.

For instance, the gpg key used to sign fedora21 packages with an openpgp
key ID containing "[email-masked]" might not have any mailbox
associated with it. It is merely shared in the DNS under an email address,
without a mailbox or valid local-part.

> management fairly represents its users

Correct, the domain's management that controls either DNS or SMTP servers,
can steal a users email.

> That's not a ridiculous model, but if

>From the Introduction:

    This document specifies a method for publishing and
    locating OpenPGP public keys in DNS for a specific email address
    using a new OPENPGPKEY DNS Resource Record.  Security is provided via
    DNSSEC.

So your point is made already pretty clear in the introduction
already. Security comes from DNSSEC, so whoever controls the domain,
controls the publishing of openpgp keys.

Section 5.2 also contains some advise. Section 7.4 also mentions this,
but not under a section title that makes that very clear.

Some clarifications will be made, especially in the security
considerations section, to clarify this, based on the IETF LC comments.

Thank you,

Paul

---

From: manning <[email-masked]>
Date: Mon, 21 Sep 2015 16:24:10 -0700

I think Paul nails it, at least for the more aware folks around.  Using the WoT to gauge anything other than confidence in choice of friends/associates is asking for trouble.
See Also:  Robin Sage :  en.wikipedia.org/wiki/Robin_Sage

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

---

From: manning <[email-masked]>
Date: Mon, 21 Sep 2015 16:55:40 -0700

Or, if your just going to nail this to email, its a whole lot easier to just insert this header..

xkcd.com/1181/

no real need to be fancy and do the actual PGP verification. Takes far to long.

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Sep 2015 18:58:43 -0500

Nonsense.  No security model is perfect.  Claiming social media connections and gpg signatures are the same thing is a logical fallacy.

Personally, I've known people for year on line, but would never sign someone's key without meeting them in person.

Complete apples and oranges comparison.

Myself, I always have gotten keys from a keyserver, never directly from the party using the key.

Scott K

On September 21, 2015 7:24:10 PM EDT, manning <[email-masked]> wrote:
>I think Paul nails it, at least for the more aware folks around.  Using
>the WoT to gauge anything other than confidence in choice of
>friends/associates is asking for trouble.

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Sep 2015 10:12:14 -0400

--On Monday, September 21, 2015 15:14 -0400 Paul Wouters
<[email-masked]> wrote:

>> Sure, but it's the way that everyone has used PGP for 20
>> years, and it's the security model that everyone I know
>> expects when they use PGP keys.
> 
> obtained directly from the person they want to exchange
> encrypted email with.

Paul,

I have no doubt that is true, but I think it has a lot to do
with Harald's comments about tools and George's comments about
models.  First, I know a lot of people who insist on keys who
are handed to them directly (or mailed with in-person or other
out of band transfer and verification of fingerprints).  I know
almost as many who almost exclusively pull things off
keyservers.  Especially with those tools that will not allow
using a key unless if bears one's personal signature (even if
non-exportable), all of those keys are incorporated into that
individual's WOT, even if the key is a self-signed one obtained
from a keyserver that no person who understood the issues and
was sane would rely upon.   Consequently, "never use the WOT"
either involves a different definition than I've used or I don't
understand what it means.    

Whether those "who to trust and why" decisions are wise or not
is another matter (and I think closer to George's concerns).

However, if you believe that, because of trust issues, people
get keys only from personal contacts rather than indirectly from
public databases, why are we discussing yet another public
database-based approach?   Or are you convinced that the problem
with the other public databases is that the DNS is inherently
better for some reason such as the inability of third parties
not associated with the domain in the address to add keys?  Or
that the DNS is somehow, inherently, the One True Database to
Rule Them All for the Internet?   (That is, of course, another
variation of my desire that the next version of the document be
much more clear about the problem(s) it is trying to solve.)

    john

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 22 Sep 2015 10:44:07 -0400

Hi Paul,

> obtained directly from the person they want to exchange encrypted 

I think most people who use any trust model use the WoT, because that's 
what the common implementations make easy.

I think most people don't use any useful trust model, though. I see a 
lot of "send me your public key in plain text so I can talk privately 
about this thing", but no appreciation for the threat models in such a 
key exchange.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Sep 2015 11:11:11 -0400 (EDT)

On Tue, 22 Sep 2015, John C Klensin wrote:

> not associated with the domain in the address to add keys?

Yes.

The other common use problem is not being able to delete keys, so you end
up using a keyserver, get a (verified by WoT) key and then in response
you get a plaintext message saying "I forgot my passphrase so i cannot
delete/revoke my old key". With DNS, you can remove the key from DNS
without needing the private key or passphrase to it.

Paul

---

From: "John Levine" <[email-masked]>
Date: 22 Sep 2015 20:11:24 -0000

>without needing the private key or passphrase to it.

There's a whole bunch of unsupported assumptions here about how mail
and DNS provisioning systems work.

While there's often a way to recover your account if you lose your
password, at large mail systems they don't work very well,
particularly if the account's been compromised and taken over by a bad
guy, which happens thousands of times a day.  (I know people at Yahoo
whose full time jobs are to deal with this.)  Even without a
compromise, it's often more hassle than it's worth to recover the
account, so you create a new one and the old one sits there
unused--that's why I'm [email-masked] rather than jrlevine.

Also, this introduces a downgrade attack.  User creates a key, gets
lots of WoT signatures, publishes it through key servers and DANE.
Bad guy takes over the account, publishes a new key with no
signatures.  According to sec 5.2 of the draft, a mail sender looks up
the key, finds they disagree, and the verification fails.  Now what?
The draft suggests dumping the question on the MUA user, which we know
is never a good idea.  As likely as not a naive user would pick the
newer key, the one that says "USE THIS KEY OLD ONE WAS STOLEN."

Finally, if the problem with existing key servers is that they won't
delete dead keys, that does not strike me as an insoluble problem.
Talk to the people who run them, suggest they add an "it's dead"
button that sends a confirmation message to the address in the key and
when confirmed, deletes the key.  The security risk is small, it is
just as secure as the DANE approach (with the advantage that existing
PGP clients work unchanged), and we're all done.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Sep 2015 16:47:18 -0400 (EDT)

> newer key, the one that says "USE THIS KEY OLD ONE WAS STOLEN."

The attacker already receives all email to the stolen account. And can
reset all services that require only email verification for a password
reset. This is pretty identical to the situation where you do not use
DNS and the attacker takes over the email account and mails all address
book entries a new PGP key.

If encryption is required for life saving, and you are confronted with a
new key, then you better check either with the person or at the minimum
check it was signed with the old known key. The fact that you pull a
new key from DNS versus a new key from a keyserver is irrelevant to
this.

> Talk to the people who run them

Please do. But it is out of scope for this draft that is specifying
a different method of publishing your openpgp keys.

> and we're all done.

That's your goal, not the goal of the dane working group when they
adopted this draft.

Paul

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 Sep 2015 09:44:57 +0600

> obtained directly from the person they want to exchange encrypted email

this is not my experience

it will be a long time before i trust a dane/dnssec identity binding
over pgp's.

At Mon, 21 Sep 2015 16:24:10 -0700, Bill Manning wrote:

> I think Paul nails it, at least for the more aware folks around.
> Using the WoT to gauge anything other than confidence in choice of

i think bill nails it.  trust in identity is what it is about for me.
i am communicating with a person, not a dns or smtp server; the latter
are agents, and ones which have failed repeatedly over the decades.

using one hierarchy to reinforce the weaknesses of another may increase
reliability (or fragility), which is good.  it does not increase trust
in identity.

At Mon, 21 Sep 2015 18:58:43 -0500, Scott Kitterman wrote:

> Personally, I've known people for year on line, but would never sign
> someone's key without meeting them in person.

bingo!  and seeing a high level out of band assertion of identy such as
a passport.

At Tue, 22 Sep 2015 08:59:25 +0200, Harald Tveit Alvestrand wrote:

> it's been obvious to me since the 90s that the hierarchical models of
> trust (CAs, corp signing authorities) are simply restricted webs of
> trust. So the WoT model is a more general one than the hierarchical one:
> you can represent hierarchy as a WoT (the user trusts the root keys,
> trust flows from there), but not vice versa.

bingo!

> I've been saddened by the crippled state of WoT-manipulating user
> interfaces since roughly forever.

but x.509 and dns end user tools are sooo much better :)

> I believe the Web of Trust has a great potential as a basis on which to
> represent many different trust policies. But the current state of tools
> to interrogate and update a trustdb according to those policies is
> simply not fit for the task.

the state of tools for the entire trust and identity ecosystem sucks.
and we are spending our time mucking below the waterline.  to a dns/dane
hammer, everything looks like a nail.  a solution looking for a problem.

At Tue, 22 Sep 2015 13:55:22 -0400, Phillip Hallam-Baker wrote:

> A few months back I realized that I had the criteria wrong. It is even
> tougher than 'do no harm'. To get people using strong crypto you have
> to do better than not making things any worse. You have to make life
> easier for the user.

'cept we're not doing that.  while i am still digging through your
latest, at least you're talking about some parts of the elephant that
i perceive.

At Tue, 22 Sep 2015 11:11:11 -0400 (EDT), Paul Wouters wrote:

> With DNS, you can remove the key from DNS without needing the private
> key or passphrase to it.

is this a feature or a bug?  good discussion in acme about having the
credentialials to add/change/delete.  in current pgp, if you think you
may ever want to revoke, gen a revocation credential.

in all these worlds, you need credentials to change or negate; to do
otherwise is a big vulnerability.

randy

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 23 Sep 2015 03:57:31 +0000

> are agents, and ones which have failed repeatedly over the decades.

We'll likely never meet in person.  You have a sensitive message
to send me about Postfix or OpenSSL or something like that.  Now
what?

Or more likely you have nothing sensitive to send me at all, but
prefer not to have your communications routinely intercepted or
stored in the clear.  Now what?

The draft strives to make PGP scale, with an inevitable trade-off
in identity assurance.  The security needs of covert-agents are
not the same as the security needs of most ordinary citizens.

Folks who want "covert agent security" need to know what tools and
systems they can't avoid trusting (a trusted party is one that can
betray you), and then, if they are careful, avoid trusting
everything/everyone else.

The rest of us need to make reasonable compromises, that protect
most of us most of the time, ideally keeping Orwellian nightmares
in check.

-- 
	Viktor.

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 Sep 2015 14:12:37 +0600

> We'll likely never meet in person.  You have a sensitive message to
> send me about Postfix or OpenSSL or something like that.  Now what?
> 
> prefer not to have your communications routinely intercepted or stored
> in the clear.  Now what?
> 
> The draft strives to make PGP scale, with an inevitable trade-off in
> identity assurance.  The security needs of covert-agents are not the
> same as the security needs of most ordinary citizens.

if i think of it as a form of opportunistic encryption with very weak
authentication it seems useful.

but when i want strong authentication i want strong introduction.

randy

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2015 11:29:05 -0400

My take here is that there are a lot of different thoughts about trust
models, and as such, I tend to agree with John and others who have
suggested the document should be more clear about its assumptions.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Sep 2015 08:35:41 -0700

On 9/23/2015 8:29 AM, Sam Hartman wrote:
> I tend to agree with John and others who have

Assumptions, models, details, etc., with operational and risk implications.

The document has a number of places that need considerable elaboration
of these.

In the case of the trust model, the document is, apparently, introducing
an entirely new 'model'.

As has been noted, the challenge of local-part handling is another,
surprisingly-basic component to the mechanism that needs careful -- and
complete -- handling in the spec, if the spec is to be a full protocol
specification.

And so on.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Sep 2015 12:01:16 -0400 (EDT)

> authentication it seems useful.

right.

> but when i want strong authentication i want strong introduction.

So pull the key from DNSSEC, check for sigs. If not good enough, you
could also pull the same key from the keyservers (now that you know
that's the key you are looking for in the pile of garbage keys on the
keyservers) and possibly get more signatures on it. Still not good
enough, don't send the email and find some humans.

Paul

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2015 12:07:23 -0400

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave> On 9/23/2015 8:29 AM, Sam Hartman wrote:
    >> I tend to agree with John and others who have suggested the
    >> document should be more clear about its assumptions.

    Dave> Assumptions, models, details, etc., with operational and risk
    Dave> implications.

Hi, Dave.
It would be easy to read the above as trying to restate  my position to
 be broader than I intended.

I'm specifically supporting the idea that the document should clearly
state its trust model.
I understand other comments have been made; I'm not expressing an
opinion on those.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Sep 2015 09:49:57 -0700

> I understand other comments have been made; I'm not expressing an

My note intended to build from yours, not clarify it.

So my note stated my views, and wasn't trying to state yours.

d/