Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>

From: "John R Levine" <[email-masked]>
Date: 18 Feb 2016 13:43:21 -0800

One other issue that hasn't come up is the security model, in particular 
what it means for a domain to publish PGP keys that it claims are 
associated with mail addresses in that domain.

The draft's introduction compares this design to existing key servers and 
argues that the key servers refusing to delete keys for which the private 
keys have been lost is a problem to be solved, although the key servers 
consider it to be a security feature.

In sections 1 and 7, it claims that finding a key through DNS lookup is 
not a substitute for web-of-trust verification, which is fine.  But 
section 5.2 says that if a domain publishes a key for an address that's 
inconsistent with an existing key, verification of the key is "treated as 
a failure."  It's unclear what the effect is supposed to be, but 
considering the discussion of the lost key problem, it appears that the 
intent is that the sender would stop using the old key.

Maybe a domain is an investment advisor ensuring that it can log its 
employees' mail, or maybe it's webmail that wants to snoop on its users to 
add intrusive advertising.  Unless a sender has external knowlege of the 
relationship between a domain and its mail users, a can of worms that I 
wouldn't want to open, this is in effect a downgrade attack.

PGP has always associated keys with users and put users in control of 
their keys; the inability to delete lost keys from keyservers is an effect 
of that. This draft moves a lot of that control to domain operators. That 
may or may not be a good idea but it's a large change to the security 
model.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Feb 2016 08:57:47 -0500 (EST)

On Thu, 18 Feb 2016, John R Levine wrote:

> One other issue that hasn't come up is the security model, in particular what 
> it means for a domain to publish PGP keys that it claims are associated with 
> mail addresses in that domain.

The security model is not changed. As stated, it is not a replacement
for the web of trust. It is another more secure location to find the
key. It can be used where otherwise a message would go out unencrypted.

> In sections 1 and 7, it claims that finding a key through DNS lookup is not a 
> substitute for web-of-trust verification, which is fine.  But section 5.2 
> says that if a domain publishes a key for an address that's inconsistent with 
> an existing key, verification of the key is "treated as a failure."  It's 
> unclear what the effect is supposed to be, but considering the discussion of 
> the lost key problem, it appears that the intent is that the sender would 
> stop using the old key.

Local policy.

> wouldn't want to open, this is in effect a downgrade attack.

That situation is unchanged from today. With the exception that
plaintext email could have been encrypted email. It's not a downgrade.

> PGP has always associated keys with users and put users in control of their 
> keys; the inability to delete lost keys from keyservers is an effect of that.

You are just cherry picking one argument. A much more severe argument is
people uploading forged keys. Ask Mr. Snowden and Mr. Assange.

> This draft moves a lot of that control to domain operators. That may or may 
> not be a good idea but it's a large change to the security model.

It does not move control around. The draft clearly states it is an
addition to the existing web-of-trust, not a replacement. It facilitates
more automated encryption where before messages would go out in
plaintext.

Paul

---

From: "John Levine" <[email-masked]>
Date: 19 Feb 2016 17:49:15 -0000

>plaintext email could have been encrypted email. It's not a downgrade.

Um, that's pretty much the definition of a cryptographic downgrade.

Thanks for confirming this security problem,

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 19 Feb 2016 13:39:00 -0500

> On Feb 19, 2016, at 8:57 AM, Paul Wouters <[email-masked]> wrote:
> 
> It can be used where otherwise a message would go out unencrypted.

I think this is the *crucial* point.  Just as DANE seems to be a good
fit for authenticating opportunistic TLS in SMTP, implementation details
aside (this draft, vs. addrquery, ...) it also seems like a good fit for
authenticating "opportunistic PGP" if I a may be so bold as to coin a new
term.

One resorts to finding keys via DNS for better than nothing content encryption
of communication with the unwashed masses.  For communication with a covert
whistle-blower one probably wants a greater level of assurance.

The PGP web of trust does not scale to ad-hoc contact with strangers, this
draft and its alternatives are to a great extent attempts to fill that gap
by providing keys for opportunistic end-to-end email encryption.  Encrypt
what you can, send the rest in the clear.

In some cases, the authenticity of keys obtained via DNS-authenticated
online queries may be verifiable out of band (call the correspondent by
phone or meet them in person and check the fingerprint, ...), then one
might use this and related drafts for key acquisition, with follow-up
verification as and when appropriate.

There is no one-size-fits-all security model for end-to-end encryption.
Neither PGP nor S/MIME dictate a single security model, except by virtue
of lack of extant alternatives.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Feb 2016 14:18:22 -0500 (EST)

On Fri, 19 Feb 2016, John Levine wrote:

Dear John,

> Um, that's pretty much the definition of a cryptographic downgrade.

I do not understand how the process of a plaintext email that goes
through this document's advise, and leaves as either still plaintext
or encrypted, could be construed as a "cryptographic downgrade".

> Thanks for confirming this security problem,

A comment like this is not only unneccessary, it is abusive and
misleading. I am requesting you to stop these personal attacks on me.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 19 Feb 2016 14:29:09 -0500

> On Feb 19, 2016, at 2:18 PM, Paul Wouters <[email-masked]> wrote:
> 
> through this document's advice, and leaves as either still plaintext

RFC7435 has not been read attentively, or perhaps is viewed as heresy:

   https://tools.ietf.org/html/rfc7435#section-1.2

   "Opportunistic Security" (OS) is defined as the use of cleartext as
   the baseline communication security policy, with encryption and
   authentication negotiated and applied to the communication when
   available.

   Cleartext, not comprehensive protection, is the default baseline.  An
   OS protocol is not falling back from comprehensive protection when
   that protection is not supported by all peers; rather, OS protocols
   aim to use the maximum protection that is available. 

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Feb 2016 18:54:11 -0500

I had promised myself that I was not going to comment further on
this until after the Last Call closes and Stephen does his
analysis, but the note below seems to indicate that we still
have different opinions about what the draft says and what we
are talking about, quite independent of what we think about it.
It seems to me that, if there is no consensus about what the
document says and people are commenting based on different
assumptions about its content, we have a problem.  That problem
may or may not be about the document itself, even if the default
assumption would normally be that the document is not clear
enough.

I'm going to try to comment about that particular "different
interpretations" situation below and keep my further "what I
think about the proposal" comments to myself for a while.

--On Friday, February 19, 2016 13:39 -0500 Viktor Dukhovni
<[email-masked]> wrote:

> I think this is the *crucial* point.  Just as DANE seems to be
> a good fit for authenticating opportunistic TLS in SMTP,
> implementation details aside (this draft, vs. addrquery, ...)
> it also seems like a good fit for authenticating
> "opportunistic PGP" if I a may be so bold as to coin a new
> term.
> 
> One resorts to finding keys via DNS for better than nothing
> content encryption of communication with the unwashed masses.
> For communication with a covert whistle-blower one probably
> wants a greater level of assurance.
> 
> The PGP web of trust does not scale to ad-hoc contact with
> strangers, this draft and its alternatives are to a great
> extent attempts to fill that gap by providing keys for
> opportunistic end-to-end email encryption.

But that is, as you say, crucial.   THe present document says,
both in the Abstract and in the Introduction that (from the
Introduction)

	"this resource record is not a replacement for verifying
	OpenPGP public keys via the web of trust signatures, or
	manually via a fingerprint verification."

Now, that seems fairly clear to me.  If the web of trust doesn't
scale, the authenticated utility of these keys doesn't scale
either.    

I can see two, maybe three possible claims in the context of
opportunistic encryption.   One is that the PGP Keyserver model
(including LDAP and other realizations) doesn't scale well or
has other fundamental deficiencies, so retrieving keys via the
DNS is a reasonable alternative to those keyservers.  As such,
it may be useful (again as a keyserver alternative) for
environments in which the web of trust works, especially if one
is willing to trust keys based on signatures of some list of
known third parties or one can verify keys based on mechanisms
other than the list of signatures on them.   It seems to me,
quibbles about exact wording aside, that is exactly what the
document says today.  However, that scales no better and no
worse than the web of trust itself because it is completely
dependent on the web of trust for authentication.

The second possible claim is that retrieval from the DNS is a
substitute for the web of trust, i.e., that you should trust a
key retrieved from the DNS (with DNSSEC, etc.) even if it is
only self-signed.   If you are making that claim, then the
scalability of the web of trust (and, to all intents and
purposes, the web of trust itself) are irrelevant.   But this
document rather clearly, at least IMO, doesn't say that.  So, if
you are advocating it on that basis, we appear to have a
disconnect somewhere. 

The third possibility depends on where you want to go with
"opportunistic", even with

>   Encrypt what you can, send the rest in the clear.

The decision is clear if you can't find a key, either through a
keyserver, the DNS, or something else.  You are either going to
decide to not send (which I don't think anyone has advocated in
this context) or you are going to send in clear.   If you get a
key but can't verify it using the web of trust, then I think the
document suggests "don't encrypt, send clear".   If your intent
is "MAY go ahead and encrypt anyway and hope for the best", I
don't think the document says that. It could, of course, but
that would probably call for a security analysis of the
implications of using a retrieved key that cannot be verified
through the web of trust.

> In some cases, the authenticity of keys obtained via
> DNS-authenticated online queries may be verifiable out of band
> (call the correspondent by phone or meet them in person and
> check the fingerprint, ...), then one might use this and
> related drafts for key acquisition, with follow-up

Sure.  But that is still well within the scope of the web of
trust, unless, again, I'm not understanding what you are
suggesting or advocating.

> There is no one-size-fits-all security model for end-to-end
> encryption. Neither PGP nor S/MIME dictate a single security
> model, except by virtue of lack of extant alternatives.

FWIW, I'm not aware of anyone, at least anyone serious, who has
claimed otherwise, at least since we stopped believing that PEM
was either a magic bullet or a magic bullet-making factory.
So, could you explain what that paragraph has to do with the
discussion of this document?

best,
    john