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
<ietf-dane@xxxxxxxxxxxx> wrote:
>
>> On Feb 19, 2016, at 8:57 AM, Paul Wouters <paul@xxxxxxxxx>
>> 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.
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
> verification as and when appropriate.
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