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

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Sep 2015 20:26:50 +0100

Hiya,

Thanks all for the energetic last call. The tl;dr version is I've
asked the authors/chairs to work on revisions as outlined below.
Those will at least need another IETF LC.

The longer version is below... and long;-)

Cheers,
S.

I went through the last call mails. I tried to separate out each of the
points raised and give my interpretation of where we're at for each.
Those marked "*SF:" (and not just "SF:") are ones where I think the
issue raised does warrant a change to the draft. There are enough of
those that I think a revised I-D is needed, and when that is ready
I'll do another IETF last call for those changes. I don't think this
needs another WGLC though, as the changes are clarifications, moving
security considerations from [OPENPGPKEY-USAGE] to here, or better
describing the experiment. (If the authors/chairs/WG want to re-do a
WGLC that'd be fine by me too.)

Note that I am not addressing what I think is an underlying objection
which I interpret as "this won't work and is hence a bad idea." I do
think folks can validly propose an experiment like this for a feature
(e2e email security) we've never managed to get deployed at scale. (By
"like this" I mean something with lots of associated and non-crazy
concerns.) Were it the case that running this experiment would break
a bunch of things I would feel differently but I don't think that is
the case.

E. Taylor [1] 20150829
- supportive but raises upper/lower case issue, suggests to
  add a "MAY lowercase"
  SF: WG decided against correctly I think.

E. Taylor [1] 20150829
- identified a bunch of typos
  *SF: Those ought be fixed.

P. Spacek, [2] 20150903
- hashing not good enough for privacy, suggests salting.
  SF: response was that salt means an odd DNS transaction, which
  seems a valid response to me, also that hashing isn't meant to (and
  won't) get strong privacy, but still marginally preferred by WG to
  non hashed LHS.

J. Levine, [3] 20150909
- scaling issues discussed in WG but not resolved
  *SF: true, we should state that that is a crucial part of the
  experiment. I mean we ought note that the scaling issues are
  not (yet) resolved, not that we ought block on resolving those.
  (As we don't know how to scale e2e email security IMO.)

J. Levine, [3] 20150909
- LHS only to be interpreted by recipient MTA, claims that this draft
  breaks that
  SF: This draft explicitly repeats exactly the MUST NOT required. A
  claim that the choice to hash the LHS as it is breaks this SMTP
  protocol requirement seems wrong.

J. Levine, [3] 20150909
- Says because of LHS issue, every variation "has to be" put into
  DNS.
  SF: I do not buy that argument. (I do not claim to know more about
  email, but the idea that email operators would have to populate
  the DNS with every possible option seems wrong.)

J. Levine, [3] 20150909
- Say that most addresses that could work with SMTP will not be in
  the DNS, leading to possible or actual failures.
  *SF: That is worth including as a consequence of this design.
  Presumably though, if all this is working, all the addresses that
  will end up used for PGP will also work in SMTP.

J. Levine, [3] 20150909
- "Hashed names require that all of the keys for a domain be served in
  one flat zone.  Large mail systems typically partition the users
  based on the local part, but since the hashes aren't reversible,
  there's no way to tell what partition would handle what hashed name."
  In a later [5] mail V. Dukhovni noted: "What does change is that the
  partitions responsible for user addresses would need to publish
  hashes to the corresponding server for the hash in question."
  *SF: I think that is correct and ought be stated as a consequence
  of this design.

J. Levine, [3] 20150909
- "PGP key records are about 3K" and so should note the impact of
  this on zonefile size.
  *SF: I think that's correct, and ought be noted. Just adding any
  RR per mailbox would have an impact, but a KB or so per mailbox
  does make that notably worse.

J. Levine, [3] 20150909
- "this draft pretty much demands name guessing."
  SF: I don't accept that and the draft says to not do that. It might
  be worth noting as part of the experiment that recording if
  implementations do/don't guess would be good.

J. Levine, [4] 20150910 (in follow up to authors)
- Suggestion to publish re-write rules as a domain specific thing
  in the DNS (maybe with a registry of standard rules)
  SF: Seems like it could be done. If this experiment was a success
  in getting deployment that should help too. But that could be
  done later.

S. Josefsson, [6] 20150910
- Mention the relationship with RFC4398 and why that approach was
  not taken.
  *SF: I think if any other change is made the explanation for this
  difference is worth adding as it was brought up a number of times
  and is non-obvious. (Since I am asking for other changes, I've
  also marked this with a '*'.)

J. Klensin, [7], 20150911
- Suggests that noting the divergence from 4398 is not enough but
  that this draft needs to be " proposing to update or depreciate the
  earlier spec"
  SF: I don't think that is a reasonable expectation for an experiment.
  Maybe we don't yet know how best to deprecate.

J. Klensin, [7], 20150911
- This draft doesn't follow the web of trust.
  SF: Neither do OpenPGP RFCs, that's one possible deployment.

J. Klensin, [7], 20150911
- "The conditions of the experiment need to be laid out,  including how
  the experiment is going to be evaluated and when"
  SF: I think more description of the experimental nature of this spec
  would be useful, but that insisting on how the experiment would be
  evaluated and when, while nice, ought not be required in an
  experimental RFC.

J. Klensin, [7], 20150911
- [OPENPGPKEY-USAGE] needs to be normative.
  *SF: I think informative references to descriptive material is fine.
  Presumably the WG may gain more knowledge of usage as the experiment
  proceeds and the end result will be better if the usage document
  follows later. However, I think John is correct in that there are
  some things in [OPENPGPKEY-USAGE] that need to be in here, e.g.
  the MUST NOT in 4.4 really ought be here. So it would make sense
  to move any security considerations text about which we're now
  confident from [OPENPGPKEY-USAGE] to here, including I guess all
  2119 MUST-level conditions that would apply to implementations of
  this.

J. Klensin, [7], 20150911
- "The Introduction to the I-D should be rewritten to explain
  why this is being done and what problem it solves."
  SF: I think both are clear enough already in the current text
  for any reader who cares to implement or experiment with this
  and who has the requisite skills/knowledge to do that.

[1] https://mailarchive.ietf.org/arch/msg/ietf/5uuauzlKTL_OJenfOHXHElF2Ia8
[2] https://mailarchive.ietf.org/arch/msg/ietf/6TmgAvww0wBOQJ4MTIyB3PO80q4
[3] https://mailarchive.ietf.org/arch/msg/ietf/_kUe6YG6BUMlI43I65okFhqR6L8
[4] https://mailarchive.ietf.org/arch/msg/ietf/_Fsbt4zxIZO6j_Z9DTW00elkqqE
[5] https://mailarchive.ietf.org/arch/msg/ietf/ZWqkTsa2yXsB9SIlkHIWUkwYNgQ
[6] https://mailarchive.ietf.org/arch/msg/ietf/TfRrOlvpislNQQPePY8N5wA6ZM4
[7] https://mailarchive.ietf.org/arch/msg/ietf/kqJmGNzfTJNhr3wXEQZuG-6k9ZE

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Sep 2015 12:33:57 -0700

> a bunch of things I would feel differently but I don't think that is

Arguably, a failure of this mechanism could be quite serious.

In fact, it can fail in both directions of damage:  It can create a
blocked channel between originator and recipient, and it can create a
false sense of having a protected channel.  How are these not
significant breakage?

More generally, the idea that it is acceptable for the IETF to authorize
an experiment for which basic questions of feasibility have been raised
but not meaningfully resolved re-emphasizes the problem with not
specifying what, exactly, is the purpose of the experiment and how
efficacy, or its lack, and success or failure will be assessed.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Sep 2015 20:42:45 +0100

Hiya,

> Arguably, a failure of this mechanism could be quite serious.

One can make that argument that seriously bad things could happen,
as one can make many arguments. Making an argument does not in itself
change the probabilities though.

It seems very unlikely to me at least that this experiment would
do significant harm.

If there is information indicating serious breakage is in fact a
non-negligible likelihood that would indeed be interesting.

Cheers,
S.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 15 Sep 2015 20:41:49 +0000

On Tuesday, September 15, 2015 12:43 PM, Stephen Farrell wrote
>... 

There is a recognized risk, that publishing lists of email addresses in a public server might enable phishing and spam. This is why some people propose using salting or robust hashing, e.g.:

   P. Spacek, [2] 20150903

This is pretty much the only area where "significant damage" could occur. I suppose that it will be mitigated by the response to the WGLC.

> non-negligible likelihood that would indeed be interesting.

I think that having the experiment is appropriate. There is actually a big question about the basic idea behind the draft, publishing *users'* key in the DNS domain of the *server*. Currently, there is no requirement that users provide their server with a copy of their public key, and often no process for doing so. The experiment will tell us if this a deployment blocker, or not. If it is not, then we have a solution. If it is a blocker, then I would expect the Open PGP WG to propose an alternate mechanism.

-- Christian Huitema

---

From: John C Klensin <[email-masked]>
Date: Tue, 15 Sep 2015 21:11:05 -0400

Stephen,

--On Tuesday, September 15, 2015 20:42 +0100 Stephen Farrell
<[email-masked]> wrote:

>>> Note that I am not addressing what I think is an underlying
>>> objection which I interpret as "this won't work and is hence
>>> a bad idea." I do think folks can validly propose an
>>> experiment like this for a feature (e2e email security)
>>> we've never managed to get deployed at scale. (By "like
>>> this" I mean something with lots of associated and non-crazy
>>> concerns.) Were it the case that running this experiment
>>> would break a bunch of things I would feel differently but I
>>> don't think that is the case.
>> 
> One can make that argument that seriously bad things could
> happen, as one can make many arguments. Making an argument
> does not in itself change the probabilities though.
> 
> It seems very unlikely to me at least that this experiment
> would do significant harm.

In that sense, I agree.  It will either work or it won't, there
will either be significant uptake or there won't, etc.  My own
guess is that either a significant fraction of email users who
might be interested in installing public keys keys for
themselves this way will find that they have trouble getting the
relevant DNS records created and/or a significant number of
users who want to use it to pull public keys so they can send
encrypted messages will either discover that the key records are
not in the DNS or that they can't find them / match addresses to
them.

With two qualifications, I don't see any of those scenarios as
causing or risking significant harm.  Those two qualifications
are: 

(1) Unless the sender manages to verify the recipient key, e.g.,
by determining that the key has been signed by herself or
someone she explicitly trusts, rather than just "found it in the
DNS", there is a risk  of spoofed keys.  Whether that is a big
deal or not depends on why one wants encryption and what one's
threat model is.  The I-D more or less says that, but it is not
obvious (especially in the light of the last sentence of the
abstract). I think it needs to be called out and explained as
part of the Security Considerations section (more on that
below).   However, should such spoofing occur, compromise
something important, and draw publicity to the compromised
elements, that could significantly inhibit the deployment of
either this approach or alternatives to it.  I would count that
as significant harm, even though one could argue that we have
seen so little deployment of PGP-based e2e encryption that our
aspirations should be in the range of "even a little would be an
improvement" and "better than nothing".

(2) I do see a failure here, should there be such a failure, as
having negative effects on other things we might try.   That is
a "harm" issue, one that would be considerably mitigate by
describing the experiment and evaluation conditions to the
degree possible.

In addition, as Christian more or less pointed out, if the IETF
is really making a very strong commitment to privacy, creating
an easily-harvestable source of verified email addresses doesn't
seem to be a good idea.  Perhaps the tradeoffs justify it, but
the document would be a lot better if that particular analysis
and set of considerations were explained.

That said, as an experiment and especially after a very
productive off-list discussion with the author, I have much
larger problems with the presentation in the document than I do
with the idea of doing the experiment.     I think the decision
to do another draft is correct.  I also think that the Security
Considerations section of the I-D needs to be complete and
self-contained, not dependent on references to an expired I-D.
It also seems to me that a number of objections can be
eliminated by being clear about objectives and explanations.
For example, while I've very sympathetic with John Levine's
position that all possible addresses for a user should be
accommodated, if that really isn't a goal -- if the goal is just
to be able to deal with whatever addresses can be found -- than
I think that can be said clearly and we can move on, leaving
questions of whether or not that is a good idea to the
experiment or later.  All of that seems to be consistent with
your analysis, so perhaps we are close to being on the same page.

I do have one additional issue that I hope the revised draft can
address.  Apparently, the core motivation for the hashing
procedure was a belief that the DNS could not accommodate
non-ASCII (or, more specifically, non-"preferred syntax")
characters in labels.  I think I understand the source of the
confusion.   RFC 1034 is reasonably clear and 1123 and 2181 are
very clear on the matter: while applications may impose other
restrictions, labels are just strings of octets containing
arbitrary bit patterns.     Fixing it is probably a matter for
DNSOP --perhaps draft-ietf-dnsop-dns-terminology which is
conveniently in IESG evaluation anyway-- but, whether the
hashing is reconsidered on that basis or not, this I-D should
not make assertions about DNS restrictions that actually do not
exist.

best,
    john

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Sep 2015 12:14:47 +0200

>and set of considerations were explained.

I'm curious about the attack scenario here.

Assuming the DNS zone is properly protected using NSEC3, performing a 
dictionary attack would mean either one DNS request per try or one NSEC3 hash.
I'm assuming here that NSEC3 can be made at least as expensive as any
proposed hashing scheme for the LHS of the e-mail address.

One DNS request is about as expensive as trying a RCPT TO on the mail server
itself.

So the big change is that off-line attacks become possible if off-line signing
is used. On-line signing would make attacks on DNS roughly equivalent to
attacks on the mail server itself.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 16 Sep 2015 12:46:04 +0200

Hi,

> proposed hashing scheme for the LHS of the e-mail address.

When this is true you may be right.  And I state this as someone who has
deployed DNSSEC.  Most haven't.  That's a pity.

> One DNS request is about as expensive as trying a RCPT TO on the mail server

Perhaps but you seem to think it's an either/or thing.  It seems likely
that once they're there, someone's going to try to get at them.  We
simply can't expect otherwise.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Sep 2015 09:51:31 -0400

--On Wednesday, September 16, 2015 12:46 +0200 Eliot Lear
<[email-masked]> wrote:

>> One DNS request is about as expensive as trying a RCPT TO on
>> the mail server itself.
> 
> Perhaps but you seem to think it's an either/or thing.  It
> seems likely that once they're there, someone's going to try
> to get at them.  We simply can't expect otherwise.

Eliot,

Thanks.  And agreed.

There are other operational differences that call "about as
expensive" into question.  While arrangements differ from one
provider to the next and in part because of spam and related
problems, many SMTP servers are aggressively monitored.
Rate-limiting is common as is connection filtering based on
sender address ranges and other protections.  All SMTP
connections are over TCP, which facilitates the above.   DNS
queries are, in my experience, typically less aggressively
monitors and filtered.   The I-D recommends using TCP for
OPENPGPKEY queries, but my (admittedly poor) memory of DNS
protocol details suggests that, if one only wanted to determine
the presence of a record and didn't care about the key, a UDP
query could be used, making some of the protections that are
used by SMTP servers even more difficult.

There is also no SMTP equivalent of hiding one's DNS query by
the use of forwarders or caching servers rather than direct use
of authoritative ones.

If UDP is, in fact, possible, then the DNS query is inherently
less expensive than opening a mail transaction and also exposes
the attacker to at least slightly lower odds of detection,
identification, or blocking.

Equally important, in many organizations, the DNS servers and
SMTP ones are not operated by the same people/groups and
communication between them is often not wonderful (this has been
raised as an operational objection to the whole "keys in the
DNS" story, but, if other issues are addressed, I'm comfortable
having that be an experiment).  The result is that information
about address mining via DNS may not get to the mail folks at
all or in a timely way (and vice-versa, by the way, but that
seems less important).

So "about as expensive" may not be true, especially if
effectiveness is weighed into the equation.  At a minimum, the
conditions are different enough that a probe to one cannot be
equated to a probe to the other.

FWIW, some of the issues above are closely related to the
reasons I want to see the "experiment" described.  If we can
anticipate possible issues, asking people to monitor for them
and report on them seems reasonable... and not doing so seems a
little irresponsible.

      john

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Sep 2015 16:35:10 +0200

>used by SMTP servers even more difficult.

This seems to be a great way to block a lot of progress. 

If you start storing more sensitive data is a server or service, then 
obviously you need to upgrade the protection and monitoring.

Claiming that just because when today there is no monitoring due to the lack of
sensitive data, there cannot be a proposal to store something else sounds
very circular to me.

If this line of reasoning was applied to the Internet as whole then we would
still have nothing more than an academic research project.

In this context, there is no point in spoofing the source address of a 
UDP DNS query because the attacker would need the reply. So monitoring and
rate limiting should work as well for UDP as for TCP.

>the use of forwarders or caching servers rather than direct use

In my experience, spammers seem to have access to botnets. So in many
cases the origin of an SMTP connection is already hidden.

>identification, or blocking.

If you have to include a valid source address, how does that lower the odds
of detection, etc?

Yes UDP is less expensive than TCP. However, that only becomes an issue
if lack of resources on either client or server side has an effect on the
attack.

It is safe to assume that a server should start some kind of rate limiting
long before resource exhaustion becomes an issue.

>and report on them seems reasonable... and not doing so seems a

A completely random idea. But maybe worth experimenting with is doing the
same thing over SMTP:

Require a TLS connection, probably to the mail submission port, with a 
DANE record (to get the same sort of security as in this draft) with an
'OPENPGP <mail-address>' command.

The advantage is that the LHS issues are gone. The question is if access to
port 587 is generally open to mail user agents and whether mail servers can
allow anonymous access to that port.

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Sep 2015 12:22:15 -0400

Philip,

I am not speaking for anyone else, but let me clarify one or two
things.   

I am _not_ objecting to doing this as a experiment if the
community thinks it likely enough to succeed and/or be useful.
My personal estimate of the consensus about that is lower than
Stephen's, but that is the IESG's problem, not mine.

Stephen's comments about "bad idea" apply to the question of
whether the experiment should be performed.   While I'm among
those who thinks this mechanism is unlikely to prove broadly
useful, I agree with him, do not believe that a proposal for an
experiment should be required to demonstrate that there will be
extensive deployment, and am willing to try to keep an open mind
on those subjects.

--On Wednesday, September 16, 2015 16:35 +0200 Philip Homburg
<[email-masked]> wrote:

> If you start storing more sensitive data is a server or
> service, then  obviously you need to upgrade the protection
> and monitoring.
>...

It is _not_ obvious, at leas6 judging by the number of
relatively unsecured servers and services we have floating
around the Internet.  Even among those who understand its
importance, there may be technical, operational, economic, or
policy reasons for not installing the level of protection one
would like.

Again, it is for this reason and others that I have been
advocating a clearer and more complete "Security Considerations"
section of the document and a more complete description of the
experiment being performed, including identification of those
issues that we can identify today which people should watch for
and evaluate.   To pick this one as an example, I do not recall
the current draft saying "if you deploy this mechanism, it would
be wise to be sure that your DNS servers are adequately hardened
against mail address harvesting attacks".   I note that the I-D
stops well short of saying "DNSSEC with NSEC3 MUST be used in
any zone that deploys OPENPGPKEY records".    I don't think the
spec should be blocked because of that, but do believe it
suggests a question that should be posed as part of the
experiment.

> Claiming that just because when today there is no monitoring
> due to the lack of sensitive data, there cannot be a proposal
> to store something else sounds very circular to me.

I made no such claim.   I would not have bothered to even
respond to your note had you note made the unqualified "about as
expensive" claim which I believe, from an SMTP standpoint, to be
incorrect or at least too superficial.

> A completely random idea. But maybe worth experimenting with
> is doing the same thing over SMTP:
> 
> Require a TLS connection, probably to the mail submission
> port, with a  DANE record (to get the same sort of security as
> in this draft) with an 'OPENPGP <mail-address>' command.
> 
> The advantage is that the LHS issues are gone. The question is
> if access to port 587 is generally open to mail user agents
> and whether mail servers can allow anonymous access to that
> port.

At least one other question is whether a requirement for TLS
connections to mail servers, and the connectivity model they
imply would be damaging to the usability of email.  I hope we
don't need to resolve that question in order for this I-D to
move forward but otherwise look forward to seeing a more
complete proposal from you in the form of an I-D.   Also note
that there is a proposal floating around for an SMTP extension
to allow asking the SMTP delivery server for the PGP key
associated with an address.  

A variation on that idea would be to ask the delivery server,
not for the key associated with a particular address, but for
its own key.  I haven't worked through a security analysis and
don't intend to, but one could imagine using that approach for
more or less opportunistic encryption between submission and
delivery servers without incurrent the problems associated with
hop-by-hop TLS and cleartext on relays.

Noting that, like all other SMTP transactions, the delivery
server would be free to impose whatever authentication or
authorization requirements it likes before accepting and
responding to such commends, I think those idea should be
explored further, but don't see them, or their exploration, as
blocking factor for this proposal --as an experiment-- either.

I gather from Stephen's note and some correspondence with Paul
that we can expect an updated, -06, draft with improvements to
at least the Security Considerations discussion.  I continue to
hope for a "Experiment Description and Questions" section too,
but can't usefully speculate further on it at this point.  May I
suggest that those who are not directly involved in the
production of that draft calm down and move on to (or back to)
other work, at least until that revision has cleared the WG?  I,
at least, am going to follow that suggestion -- no more comments
on the IETF list until the community is asked to review -06 or
later.

best
    john

---

From: "John Levine" <[email-masked]>
Date: 17 Sep 2015 05:54:56 -0000

>  protocol requirement seems wrong.

This draft mandates that the DNS publishes only a small handful of the
addreses that an SMTP server would accept.  RFC 5321 describes how
local-parts are interpreted, and this draft doesn't do what 5321 says.

>  the DNS with every possible option seems wrong.)

Same thing.

>  will end up used for PGP will also work in SMTP.

Yes, but not the other way around.  Note my example of john+bank@example
which works in SMTP but not in this design.

>  *SF: I think that is correct and ought be stated as a consequence

I suppose -- the partitioning for the DNS would be unrelated to the
one used for mail, so you'd need some sort of crossbar to get stuff
from the existing mail system into the DNS.  Since the mail system
can't use its existing partitions, it in effect has to publish names
into one big flat zone even if the implementation of that zone
partitions it somehow.

>  implementations do/don't guess would be good.

Note comments by draft author and others saying they're going to do name
guessing regardless.

>  in getting deployment that should help too. But that could be

Note that decades of attempts to do this have all failed, and nobody I
know who is familiar with commercial mail systems believes it is
feasible.  It is not an accident that RFC 5321 and predecessors do not
attempt to describe rewrite or canonicalization rules.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Sep 2015 02:27:08 -0400 (EDT)

On Thu, 17 Sep 2015, John Levine wrote:

> addreses that an SMTP server would accept.

I don't see that. The -05 draft does not do lowercasing. So all
addresses are accepted unless you find a sha256 hash collision. Can you
give an example of an address that would not be accepted by this
document but would be accepted by an SMTP server?

>  RFC 5321 describes how

We do not interpret/modify the local-part - we only hash it.

Same thing.

> which works in SMTP but not in this design.

It works fine in this design if you publish the record at sha256(john+bank)
or add CNAMEs for your john+FOO email addresses. Adding the CNAME's
should be easier than adding them as valid ID's on your OpenPGP key.

> Note comments by draft author and others saying they're going to do name

Correct. It is the obvious choice in real world auto-casing scenarios
versus imaginary world support for case sensitive email addresses. Some
offline discussion seems to suggest that we can re-introduce lowercasing
provided we state clearly that it does not support case sensitive
mailboxes.

> attempt to describe rewrite or canonicalization rules.

So it seems we all agree to punt this for now and not include anything
like this in the document.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Sep 2015 09:17:30 +0100

> We do not interpret/modify the local-part - we only hash it.

I think the above is repetitive of points already made in the LC.

Now, as it happens I (still) don't get John's position on this
but I plan to follow up on that off list and would suggest that
we can all do that for now, given that there will be another LC
before this draft proceeds.

S.

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Sep 2015 05:26:31 -0400

Paul,

I really want to see a new draft rather than comment further on
this, but one point below in the hope of contributing to that
draft...

--On Thursday, September 17, 2015 02:27 -0400 Paul Wouters
<[email-masked]> wrote:

>> Yes, but not the other way around.  Note my example of
>> john+bank@example which works in SMTP but not in this design.
> 

I either still don't understand how you are proposing that this
works or what you are saying (here and in the document) is
contradictory.

AFAICT at this stage (including our off list conversation),
there is no requirement that all addresses have matching DNS
entries so that, if I use [email-masked],
[email-masked], and [email-masked] but create
corresponding DNS entries for only the first two, I won't get
encryption for the third.  That makes me no worse off than I am
today for that third address and better off for the other two.
Since John Levine and others read the document differently, I
encourage you to clarify that in the next version (if it is
correct and more important if it isn't).

Assume we mark up everything we don't know for sure, including
how useful the approach will be with the above and whether or
not hashing [1] is useful, to "experiment" and move on for now
[2], I still don't understand the relationship among the email
address, DNS label, IDs on the PGP key, and PGP key validating
signatures.   See if the following clarifies where I am confused.

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.

Ignoring [email-masked] entirely because the recipient
declines to put a record for it in the DNS, and using
"transform()" for whatever hashing and label-adding you apply to
get to the record owner you want...

Case 1: Assume that recipient has a PGP key with email addresses
[email-masked] and [email-masked] on it, both signed
by someone trusted by the sender.   The DNS records are
   transform([email-masked].) IN OPENPGPKEY key...
   transform([email-masked].) IN CNAME
transform([email-masked])

Now, for this case, neither of the transformed forms actually
appear on the PGP key, so any signature-checking has to be done
against the original email addresses.  That is fine from a PGP
standpoint.  However, DNSSEC provides no help because one cannot
presume a trust relationship between example.com. and
example.foo.: all DNSSEC validation of the CNAME proves is that
the record is intact.  In particular, it doesn't indicate that
example.com has given permission for the alias nor that there is
any real relationship between the names from a trust standpoint.
I hope that is clear; if it is not, note that 
   transform([email-masked].) IN CNAME
transform([email-masked].)
would validate equally well (and would validate whether
evil.example.org actually exists).

Case 2: As above, but you expect your hash to be added to the
PGP key as an address to be signed by everyone who has signed
the other two addresses on the key.  That is a big deployment
factor that doesn't appear to be mentioned explicitly in the
draft.  Things still work, but, because of that deployment
factor, "opportunistic" takes a step backwards.  Because
addresses on PGP keys are generally assumed to be real email
addresses, the would-be recipient has to be sure that the hash
is considered a valid address by whatever delivery server is
being used and add it as an email alias.   That is an even
bigger deployment issue, especially if either the hash is not
considered to be a valid address at that server or the server
operator does not support mailbox aliases (only separate
mailboxes).  I'm happy to leave the question of whether there
are enough restrictions in practice to make your approach
infeasible as an experiment, but I think that needs to be
spelled out.

Note also that this implies that, if I don't use CNAME (see
below), every time I create a new OPENPGPKEY record, I need to
add that hash to the key and get it re-signed.

Case 3: Only [email-masked] and/or the hash part of
transform([email-masked])  appear on the key and are
appropriately signed and the DNS records are as above.  I
suggest that, because of the DNSSEC CNAME issue _and_ the
absence of an address and signature associated with
[email-masked]., that address must be considered
inappropriate for the use of PGP.

So "adding CNAMEs for..." just doesn't seem to me to be helpful,
at least without further explanation of what you have in mind or
some intra-zone restrictions.

There is another twitch in this that is as much a PGP issue as
anything to do with your approach.  Latent in some of my earlier
comments, and maybe some of John Levine's, is the fact that, if
I have a properly set-up and signed key for [email-masked],
I'd like that to be considered the key for [email-masked]
but not for [email-masked].  John might have a different
preference. We would both also like ponies because the only
thing that keeps those preferences from violating the 5321 "no
interpretation except by the delivery server" rule is that we
control the addresses and how they are interpreted by the
relevant delivery servers.   If a sending MUA or Submission
server says anything equivalent to "I see [email-masked],
I should look up a key for [email-masked] and use that to
encrypt" it has crossed the line, at least absent out of band
instructions that are specific to how I organize addresses [3].
An SMTP relay that does it is out of line under _any_
circumstances.

best,
   john

[1] I believe hashing is unnecessary, a potential source of
confusion, and a waste of time and energy.   Depending on how
the hash is used, I think it violates the intent of the RFC 5321
prohibition, but not necessarily the latter.   I don't know that
it is harmful except insofar as it reduces the usability of this
feature (and that, it seems to me, is a reasonable experimental
question) [2].

[2] Again, I hope you will describe what is actually considered
experimental in the next version and will probably protest
further if you do not... precisely because these sorts of issues
show why that is important in this case.

[3] A standard for subaddresses might help with this and might
justify changes to sending MUA and/or OpenPGP interpretation of
addresses for lookup, but we have no such standard.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Sep 2015 11:23:46 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> one cannot presume a trust relationship between
    John> example.com. and example.foo.: all DNSSEC validation of the
    John> CNAME proves is that the record is intact.  In particular, it
    John> doesn't indicate that example.com has given permission for the
    John> alias nor that there is any real relationship between the
    John> names from a trust standpoint.  I hope that is clear; if it is
    John> not, note that transform([email-masked].) IN CNAME
    John> transform([email-masked].)  would validate equally
    John> well (and would validate whether evil.example.org actually
    John> exists).

That's clear, but I don't understand why I care.
If we except the premis that the folks running the DNS for example.foo. should
be able to make assertions about which PGP keys to trust for email
addresses ending in example.foo., why do we care what
example.com. thinks of the matter?
If example.foo. wants to delegate trust in a key, what's wrong with them
doing so.  It seems reasonable for example.foo. to say they trust the
folks over at example.com. to stick the right key in DNS.

So, I see no reason why example.com should need to validate the alias.

This does mean that example.foo. can publish dns records, and if those
records are trusted they can cause their users to get encrypted mail
that the users cannot read.
It seems like example.foo. can break email for example.foo. by
publishing a variety of DNS records and that's nothing new.

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Sep 2015 16:40:37 -0400

--On Thursday, September 17, 2015 11:23 -0400 Sam Hartman
<[email-masked]> wrote:

>     John> example.com. and example.foo.: all DNSSEC validation
> of the     John> CNAME proves is that the record is intact.
> In particular, it     John> doesn't indicate that example.com
> has given permission for the     John> alias nor that there is
> any real relationship between the     John> names from a trust
> standpoint.  I hope that is clear; if it is     John> not,
> note that transform([email-masked].) IN CNAME     John>
> transform([email-masked].)  would validate equally
> John> well (and would validate whether evil.example.org
> actually     John> exists).
> 
> If we except the premis that the folks running the DNS for
> example.foo. should be able to make assertions about which PGP
> keys to trust for email addresses ending in example.foo., why
> do we care what example.com. thinks of the matter?
> If example.foo. wants to delegate trust in a key, what's wrong
> with them doing so.  It seems reasonable for example.foo. to
> say they trust the folks over at example.com. to stick the
> right key in DNS.
> 
> This does mean that example.foo. can publish dns records, and
> if those records are trusted they can cause their users to get
> encrypted mail that the users cannot read.

Sam,

I don't know if you should care.  I don't even know if I care.
My problem is that I believe there are two possible trust
scenarios/ assumptions here.  I want the document to be clear
and absolutely consistent about which scenario applies or, if
both do, what the conditions are that distinguish them.

FWIW, these scenarios are much more important if one is going to
rely on digital signatures associated with the key.  If the keys
are merely to be used for email encryption and one is willing to
rely on the belief that, if the wrong key is picked up (by
accident or malice) and a message encrypted to it, that is
harmless because the entity who owns the private key won't
receive the message and the entity who does receive the message
won't be able to decrypt it.   If that is the assumption, I'd
like to see it spelled out in the document, possibly with a
SHOULD NOT for use with signatures and/or in conjunction with a
discussion of high-value data and MITM attacks [1].

Scenario #1: While the DNS is a way, maybe even a reliable way,
to locate a key, actual trust in the key depends entirely on
what addresses are embedded in it and whether relevant addresses
have been signed/ certified/ validations by already-trusted
parties.  In that case, I don't care very much what happens with
or in the DNS although I certainly prefer the protections that
DNSSEC offers.

Scenario 2: The message originator is expected to trust the key
based on finding it in the DNS, regardless of whether the email
address of interest is embedded in to the and regardless of
whether the key is signed by a known and trusted party.  For
that case, DNS relationships are, I think, quite important,
including specifically whether a registrar or domain
administrator should be considered trusted parties by virtue of
those roles.   In that regard, DNSSEC is very useful for
assuring the integrity of DNS responses, but has nothing to do
with whether the parties who entered data into the DNS can be
trusted.

Again for the purposes of carrying out an experiment to see how
well this works and how much it is used, I really don't care
what the answers to the above questions are.  I just want the
questions written down and, if the answers can't be written down
too, the text should include explicit statements that the issues
should be examined during the experiment. 

best,
    john

[1] In the last couple of weeks, I have been having a battle
with a correspondent who would like me to transmit some very
high value personal identification information over clear text
email.   The data are high value in the sense that having it
would be close to the fondest dreams of a would-be identity
thief.   They also want it transmitted to an address that will
be receiving few other types of information, so someone who
could compromise that mailbox or the path to it would end up
with high-value information on a lot of people with little
requirement for additional effort.  They have also, by the way,
offered a web site as an alternative that does not support even
rudimentary SSL 1.0 HTTPS so the options at present are two
different versions of clear text and MITM vunerability for
easy-to-identify addresses or web sites.   So I have been asking
myself the obvious question of whether, if a PGP key were
published for that mailbox, what it would take for me to trust
it enough to use it to encrypt and send that high-value data or
whether, for example, I am better off putting the information in
an envelope or two and trusting the post or some courier
service.   A large fraction of my questions about relationships,
trust models, and attack scenarios are the result of those
thought experiments, as are some that have not come up (at least
so far).  

As an example of the latter, the mailbox in question is read by
a group of people.  If they published a PGP key associated with
the mailbox, presumably everyone in the group would have access
to the private key.  From a web of trust standpoint, that is
problematic, especially in the absence of really good key
revocation arrangements.  If the trust model is close to
Scenario 2 above, maybe one doesn't care as much.   Or maybe one
can't trust such a mailbox at all.

---

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:
> 

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: "John Levine" <[email-masked]>
Date: 21 Sep 2015 17:21:09 -0000

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: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Sep 2015 08:59:25 +0200

Warning: random PGP musings ahead....

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.

I've been saddened by the crippled state of WoT-manipulating user
interfaces since roughly forever.
They seem to be utterly incompetent in answering questions like:

- Are there any friends who have signed for this guy?
- Who do I need to trust in order to trust this guy's key?
- Who are the guys that signed this guy's key, and how can I insert them
all into my keystore?
- How well is he connected into the Web of Trust - is it just one arc,
or a good mesh?

And of course they all seem to have been tested with a trustdb of ~20
keys; doing anything on a trustdb the size of my email directory (order
of magnitude 1000) is just too slow for words; copying the signers of my
correspondents' keys into my keystore would render the UI completely
useless.

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.

Harald

---

From: George Michaelson <[email-masked]>
Date: Tue, 22 Sep 2015 10:09:06 -0300

I also think this is worth thinking about.

The concept of co-signing which has been discussed in X.509, and some of
the sunlight on certificates concepts seem to me to go into the same space:
constructing enough community trust in a *process* that I can make a
judgement call on the six degrees of kevin bacon between me, and some
unknown PGP identity.

I am not entirely naieve. I know the friend-of-a-friend model has innate
weaknesses. But since we also know (Diginotar, Egyptian RA of CNNIC CA)
that the hierarchical model has operational weaknesses, I think we've
served ourselves a false dichotomy.

This problem feels to me n-dimensional. You touch on one: the tools. I
touch on another: the organisational processes which govern use of the
tools.

Even just running key parties is a royal pain. I had to call on two
subject-matter experts to help me bootstrap the shell level primitives for
key exchange after the last one I attended at RIPE-Amsterdam: the code
simply didn't *work* with the mail clients we now have. I could sign fine:
I couldn't construct the PEM encoded exchange to send back to the people I
had co-signed.

Good on you, for bringing this up Harald.

-G

---

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: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Sep 2015 13:55:22 -0400

> They seem to be utterly incompetent in answering questions like:

In the wake of PRISM I set out to design a system for end to end email
security that would meet a longstanding usability goal I had suggested of
making secure use of the application require mo more effort than insecure
use.

SSL was successful because it demands absolutely nothing of the user. The
user does not even have to look at the padlock icon if they don't want to
and they certainly don't need to do checks unless they have a security
concern - visiting their bank site for example.

People did point out that SSL isn't ideal and they are right. SSL came out
in 1995 when standards were much lower and users were willing to learn new
things. Today the standard for usability is the iPhone/Jobs standard. If
you would not be comfortable pitching the scheme to Steve then don't bother
proposing it.

So I have demonstrated my S/MIME client that does not demand anything of
the user beyond running the profile application once. PKI should never
require effort on the part of the end user. If a procedure can be reduced
to a set of 'easy to follow instructions' it can be reduced to code. And
code is much cheaper than customer service calls. There is absolutely no
reason you can't automate every step in PKI management. The original
PROSMProof scheme uses S/MIME because that is what is already supported in
the email clients. The plan all along was to support both S/MIME and
OpenPGP for production.

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.

Which is how I came up with the idea of the CryptoMesh which has a primary
function of serving as a username/password manager that cannot be
compromised by a cloud breach. It also makes it really easy to configure
new devices with existing network settings. So instead of having to type in
that incomprehensible nonsense to configure your inbound/outbound server
ports (there are three possible values for each) for each new phone, that
can be copied.

The Mesh will also copy the crypto configuration at the same time of
course. And why wouldn't the user have one?

At this point it is clear that everyone thinking about the problem
seriously understands that:

* There are applications where a hierarchical trust model is essential
(e.g. government use).

* There are applications where it is not.

* There are situations where a direct trust model (i.e. fingerprint of key)
is appropriate.

* There are situations where an opportunistic trust after first contact
approach is appropriate.

* All of these are sub-classes of a Web of Trust approach.

The last point is important because trust links are like GOTO statements.
If you don't have some structure and discipline when you use them you are
going to have no idea what you have created actually means.

To work out what a trust link means you have to have a model. The model I
use is to look at the work factor required to make a false claim. This is a
dollar cost rather than a number of CPU cycles but it is still a work
factor.

The reason blockchain/CT/hashchain type approaches have so much power is
that they increase the work factor to essentially infinity for postdating
an assertion.

I don't see the DANE approach as remotely practical for any user based
assertion. I don't think it has much work factor leverage either. It is
much easier for an attacker to compromise my DNS provider than the systems
I control directly.

But getting back to Harald's original challenge, there are plenty of ways
of automatically generating interesting Webs of Trust.

For example, lets sat my UDF fingerprint is MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ

Lets say that this email had that fingerprint in the email headers:

To: [email-masked]
From: [email-masked]
SenderUDF: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ

Now lets say one of you sends me an email and your email client presents me
with a challenge:

To: [email-masked]
From: [email-masked]
SenderUDF: MIRXW-4J3UE-BDHKY-3LEBI-GSZ3T
Challenge: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ;
    nonce=KRXXE2LFOMQGC3DMEBTHKY3LEBYGSZ3TBI

At this point your email client has presented my email client with a
challenge against my purported personal PKI. My client can now respond and
prove to you directly that a party with a key that is credentialed under
the original fingerprint

To: [email-masked]
From: [email-masked]
SenderUDF: MIRXW-4J3UE-BDHKY-3LEBI-GSZ3T
Challenge: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ;
    nonce=JF2HGIDHN5UW4ZZANFXCAYJAOBUWO4ZANVXXK
Proof: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ;
    nonce=KRXXE2LFOMQGC3DMEBTHKY3LEBYGSZ3TBI ;
    nonce2=KNUXIIDEN53W4IDZN52XEIDGOVRWW2LO ;
    value= NB2HI4DTHIXS653XO4XHS33VOR2WEZJOMNX
      W2L3XMF2GG2B7OY6UMQTQKFFDSODSKI2G6CQ

This type of trust building mechanism can be made completely transparent to
the end user.

Now to make this completely seamless and cope with real corner cases you
need a lot of PKI. But the user doesn't need to see any of it.

People who are asking whether OpenPGP or S/MIME is the answer are both
wrong. Both specs have a message format but neither is sufficient to meet
real world needs for a personal PKI.

OpenPGP fingerprints are a good idea. But the fingerprint that is exchanged
should be the fingerprint of a personal trust root and not a particular
application key. Binding everything to application keys made sense in 1995
when few people even had access to more than one device and machines were
slow making path math a major drag. Today we have different requirements
and fewer CPU constraints.

Anyway, I am going back to complete the code between laughing at my Oxford
acquaintance who is now trying to make my sort of work criminal in the home
country.

I really need a lot more help to make this happen. If people want to build
a trust infrastructure that makes the Web easier to use then lets do it.

---

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.

> trust flows from there), but not vice versa.

bingo!

> interfaces since roughly forever.

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

> 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:

> 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: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Sep 2015 07:29:37 +0200

> without needing the private key or passphrase to it.
Actually the DNS manipulation is not deleting a key; it's preventing it
from being found.

Revocation is "I, the signer of this revocation, declare that this key
is not worthy of trust".
(the difference between a CRL and a PGP-style revocation is who signs
the revocation - both have their place in the pantheon of web-of-trust
models.)

Deleting from the DNS is just making the key (and its signatures) harder
to find.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Sep 2015 07:34:16 +0200

On 09/22/2015 04:44 PM, Joe Abley wrote:
> I think most people who use any trust model use the WoT, because
that's what the common implementations make easy.
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.
This is actually a very rational model. It reduces the attack surface to
one leap of faith - which has been very successful for SSH.

I keep a keystore on all my mailers, but haven't bothered to build any
trust networks recently. This will allow me to detect certain kinds of
attacks (damaged messages, multiple keys claiming to be for the same
person) without causing me to spend time managing my keystore.

For me, that's a reasonable tradeoff.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Sep 2015 08:06:28 +0200

> For me, that's a reasonable tradeoff.
And the mailing list server + my PGP defaults conspired to illustrate my
point by rendering my signature unverifiable.

Sigh.

---

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: Philip Homburg <[email-masked]>
Date: Wed, 23 Sep 2015 14:55:51 +0200

>stored in the clear.  Now what?

Assuming just normal e-mail, nothing extremely sensitive, why do (some of
us) have higher requirements for e-mail than for web servers?

For sensitive e-mail, yes, find an out of band way to verify someone's
key. And sign it yourself.

But for ordinary e-mail, if we can trust the CA system to protect websites,
why not trust DNSSEC to protect e-mail?

---

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: "John Levine" <[email-masked]>
Date: 23 Sep 2015 15:35:23 -0000

>in identity assurance. ...

I've been trying to figure out what this draft provides that the
existing widely implemented PGP keyservers don't.  So far, it seems to
be that in some cases it's easier to delete dead keys, although that
makes some significant assumptions about how the provisioning systems
work.

We seem to agree that the security isn't very different: if the
domain's management can run the DNS securely and truthfully represents
its users' interests, DANE might be better, otherwise not.  Since the
most plausible usage scenario is opportunistic encryption to
recipients, it doesn't really matter where the keys come from.

For reasons discussed earlier, I don't think that publishing millions
of keys in the DNS is likely to scale well, certainly no better and
probably much worse than on the web where there are already plenty of
giant databases.

What am I missing?

R's,
John

---

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/

---

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:01:50 -0400

>>>>> "John" == John Levine <[email-masked]> writes:

    John> I've been trying to figure out what this draft provides that
    John> the existing widely implemented PGP keyservers don't.  So far,
    John> it seems to be that in some cases it's easier to delete dead
    John> keys, although that makes some significant assumptions about
    John> how the provisioning systems work.

I also think you have higher trust in dnssec-validated keys than a key
that you get from a key server without a trust path to some key you
trust.

Key servers are a publicly writable database with no level of assurance
in the contents implied by an entry existing in the database.
dnssec can give you greater assurance if you trust the domain owner.

I think this is mostly a terrible idea, because it might lead to me
getting some significant quantity of pgp-encrypted email if successful,
and I can think of few worse things than having to deal with significant
quantities of encrypted mail:-)

However I agree with the authors that it would actually make it easier
to find pgp keys that you have some degree of trust in.

---

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

> recipients, it doesn't really matter where the keys come from.

Of course it does. I can upload a new and stronger key with keyid
[email-masked] to the keyservers and now you cannot read any email people
send you that is automatically encrypted to a key you don't own. You can't
trust the keyservers for the binding between keyid and email address.

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/

---

From: "John R Levine" <[email-masked]>
Date: 23 Sep 2015 13:44:07 -0400

> that you get from a key server without a trust path to some key you

Not really.  The only credible assertion a self-signature like DNSSEC can 
make is "this is me."  But in this case it's "this is my user" which is 
not the same thing.  Unless you know something about the relationship 
between the domain and its mail users, that might be anywhere from 
completely true to completely false.

If it's false, it doesn't have to be false for malicious reasons.  If I 
ran a webmail service, call it GooHoo, I'd publish keys for all my users. 
Why not?  The opportunistic encryption keeps random strangers from 
snooping on incoming mail, webmail pretty much requires that the mail 
service handle the encryption (there are plugins, but I've never found one 
that was at all usable), and I can continue to enhance the experience of 
my webmail users by displaying relevant ads from our trusted marketing 
partners.

Also, it seems to me that most of the complaints about key servers could 
be fixed by improving the key servers, without having to change the 
existing pgp clients that use them.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 23 Sep 2015 18:08:34 -0000

>trust the keyservers for the binding between keyid and email address.

I understand the argument for better keyservers, e.g., you have to
click on a URL in a message encrypted to the key before they publish
it.  I don't understand the argument to replace it with something else
with a whole new bunch of security and other issues.

R's,
John

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2015 14:30:02 -0400

>>>>> "John" == John R Levine <[email-masked]> writes:

    >> I also think you have higher trust in dnssec-validated keys than
    >> a key that you get from a key server without a trust path to some
    >> key you trust.

    John> Not really.  The only credible assertion a self-signature like
    John> DNSSEC can make is "this is me."  But in this case it's "this
    John> is my user" which is not the same thing.  Unless you know
    John> something about the relationship between the domain and its
    John> mail users, that might be anywhere from completely true to
    John> completely false.

Let's focus on the case where it's completely false, yet it's still
reasonable to trust the domain to publish the right MX records.  I'm not
seeing that case at all, so I'd appreciate some help.

    John> If it's false, it doesn't have to be false for malicious
    John> reasons.  If I ran a webmail service, call it GooHoo, I'd
    John> publish keys for all my users. Why not?  The opportunistic
    John> encryption keeps random strangers from snooping on incoming
    John> mail, webmail pretty much requires that the mail service
    John> handle the encryption (there are plugins, but I've never found
    John> one that was at all usable), and I can continue to enhance the
    John> experience of my webmail users by displaying relevant ads from
    John> our trusted marketing partners.

Is this supposed to be a case where it's completely false?
If so, I'm not seeing it.
I think it would be reasonable for a webmail service to generate a key
at account creation time and to publish these records for that key.

I'm not seeing the case where it's likely to be completely false for
malicious or other reasons.  I mean, yes, yoru DNS operator could mount
a DOS on your mailusers by publishing bogus PGP key records.  Why would
their incentives be aligned with doing that in cases where you're
willing to trust them enough to publish MX and other mail related
records?

---

From: "John R Levine" <[email-masked]>
Date: 23 Sep 2015 15:00:06 -0400

I should have been clearer, the assertion is "this is my user's key".

> seeing that case at all, so I'd appreciate some help.

A straightforward example is that the mail system, through malice or 
outside pressure, does an MITM attack on users who have their own keys, so 
it publishes a key it controls and re-encrypts mail on the way through to 
the user's own key.  An outsider who had the old key might notice that the 
key changed, or if he didn't have the old key, probably not.

Or if I were a domain operator who was lazy in a certain sort of way, 
rather than opening up my creaky provisioning software to add a way for my 
users to put keys into my system, every once in a while I'd just pull 
whatever keys I could find on outside key servers and publish those.

My point is that unless you know about the domain's relationship with its 
users, keys provided this way are no more credible than keys from anywhere 
else.  DNSSEC has not added anything useful.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Sep 2015 21:29:47 +0200

On 9/23/15 9:00 PM, John R Levine wrote:
> outside pressure, does an MITM attack on users who have their own
> keys, so it publishes a key it controls and re-encrypts mail on the
> way through to the user's own key.  An outsider who had the old key
> might notice that the key changed, or if he didn't have the old key,
> probably not.
>

The good news is that this should be observable by the user.  That is,
he should be able to query the domain for his own public key and
compare.  But there are many corner cases.  One might be if a parent
zone hijacked the entire domain; sent mail as the user and sent mail as
some set of that domain's users, causing them to think that a
communication was trusted.  Assume this happened because the parent got
hacked.

That could be mitigated by a warning from a client to a recipient that
the keys have changed, but we know how well warnings work.  Is this any
worse than a CA being hijacked?  You yourself argued to me on this list
some time ago that it is, at least in part, because all of this is tied
to a single-rooted hierarchy.  But for an experiment, it might be fun to
see how these sorts of bugs could be kinked out (or if they can be).

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Sep 2015 15:38:55 -0400

> why not trust DNSSEC to protect e-mail?

That isn't really the reason to be concerned.

What worries me is that DANE is one way to use DNSSEC to secure things.
DANE is not necessarily the best way to apply DNSSEC. DNSSEC is not
necessarily the best tool to approach this problem.

And we have the fact that the Snowden documents tell us that $250 million
is spent every year on the BULLRUN program to sabotage standards efforts to
produce strong crypto.

My #1 concern is that some of the folk behind this proposal have a long
history of sharp elbows. As soon as they get an IETF endorsement for their
scheme, they then use it to tell other people with other ideas that they
must stop working about them, stop talking about them because THE DECISION
HAS BEEN MADE.

It is total bullcrap of course. And most of us know not to get suckered in.
But that has been done to me repeatedly and I am sick of it. So I would
like any document to have a disclaimer at the top of every page saying that
this is only experimental and does not commit the IETF to one particular
approach.

OK so that said, about using DNSSEC. I don't think it is going to get
anywhere because most people don't have the required control over their DNS
to make this happen. that might change in the future but people have been
trying to put email addresses into DNS records since the first edition of
the spec and none of those schemes has been successful.

If you want a scheme that might be used by a few hundred thousand system
administrators, well it is better than nothing at all and might be
successful. But this is no solution to the problem of pervasive
surveillance and people need to be aware of that.

---

From: "John R Levine" <[email-masked]>
Date: 23 Sep 2015 15:42:10 -0400

> The good news is that this should be observable by the user.

Sure, but once again you're no better off than if you got the key anywhere 
else.  I understand the argument for better key servers and maybe better 
ways to discover key servers (a URI record should do it), but I don't 
understand the argument for a whole new mechanism with new security, 
scaling, and semantic problems.

Regards,

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 23 Sep 2015 21:55:33 +0200

Eliot Lear <[email-masked]> writes:

> compare.

The user can't detect it reliably, I believe, at least not until we have
something like a Certificate Transparency project for DNSSEC data.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2015 15:56:34 -0400

>>>>> "John" == John R Levine <[email-masked]> writes:

    John> I should have been clearer, the assertion is "this is my
    John> user's key".
    >> Let's focus on the case where it's completely false, yet it's
    >> still reasonable to trust the domain to publish the right MX
    >> records.  I'm not seeing that case at all, so I'd appreciate some
    >> help.

    John> A straightforward example is that the mail system, through
    John> malice or outside pressure, does an MITM attack on users who
    John> have their own keys, so it publishes a key it controls and
    John> re-encrypts mail on the way through to the user's own key.  An
    John> outsider who had the old key might notice that the key
    John> changed, or if he didn't have the old key, probably not.

I think this is OK.
That's what you get for using a domain who does this sort of thing as
your email provider.

Especially if the domain insists on being able to decrypt email and this
is their way of trying to not break encryption, I think you'll get
better results than with the key servers.  Yes, you have an annoying
choice as a sender: trust the new key and let others read the encrypted
traffic or use a key you get elsewhere and have your mail fail to
deliver.

So, no I don't consider this a case where this proposal results in the
wrong thing happening.
I do consider this proposal's handling of this case superior to the key
servers.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 23 Sep 2015 12:03:10 -0800

I think I'd understand the objections and agree with many of
the concerns being expressed if this were a standards-track
document, but it's not.  It specifies a record type for
experimental purposes, to increase the likelihood that people
playing around with implementation implement the same things.
It's somewhere between annoying and frustrating that an
experimental document is being held to the same level of
baked-ness that we expect of an internet standard.

2026 says:
   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual contribution.

And it seems that the review being received here goes *well*
beyond what's described.  We know that there are problems with
trust models being used in existing protocols, and we know
that the problem of the left-hand side of email addresses
can be extremely difficult.  I would suggest that shutting
this publication down will tend to move us further away from
solving them, not closer.

This document represents working group consensus about an
experiment they'd like to see happen.  Given that there is
general agreement within the community most directly concerned,
it seems to me that the questions should be: 1) is this
sufficiently well-specified to be able to produce interoperable
implementations, and 2) does this break anything currently in
use?

We have seen no shortage of experimental specifications that never
were widely deployed (or deployed at all), and I'm really not sure
I understand the resistance to seeing this published as an
experimental RFC.  Certainly most of the objections I've been
seeing are demanding rigor that we really should not be
expecting from an experimental document, and they are inconsistent
with our own well-documented criteria for experimental RFCs.

Melinda

---

From: George Michaelson <[email-masked]>
Date: Wed, 23 Sep 2015 17:05:38 -0300

> something like a Certificate Transparency project for DNSSEC data.

+1. This is a good idea. More sunlight on (DNS, web, other) certificates is
a good thing.

I have no particular problem with keyservers remaining outside of the DNS
payload ecology btw. I feel this is a bit like discussions of OCSP:
wonderful idea, no traction. Thats what keyservers feel like.

DNSSEC has compelling qualities of ubiquity and reach, combined with signed
chain. John Levine's argument takes me to believe there is no innate
value-add from the DNSSEC in the fetch of the data over any other path, but
it is ubiquitous, and widely distributed where keyserver.pool.org is
inherently scale-nasty until somebody in CDN land steps in to make it scale.

-G

---

From: "John R Levine" <[email-masked]>
Date: 23 Sep 2015 16:13:44 -0400

> I think this is OK. That's what you get for using a domain who does this 
> sort of thing as your email provider.

Right.  But again, if I'm trying to find your key, I have no way to know 
how sleazy your mail provider is, so I have no way to tell whether to 
trust the keys they publish.

> I do consider this proposal's handling of this case superior to the key

A key you get from the key servers might be real or might be bogus.  A key 
you get through DANE might be real or might be bogus.  What's the 
difference?  A key from DANE implicitly has an endorsement from the 
domain, but a key from key servers can have endorsements via WoT 
signatures.  In each case. unless you know the endorser, the endorsement 
is useless.

R's,
John

---

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

On Wed, 23 Sep 2015, John R Levine wrote:

> else.  I understand the argument for better key servers and maybe better ways 
> to discover key servers (a URI record should do it), but I don't understand 
> the argument for a whole new mechanism with new security, scaling, and 
> semantic problems.

Some people disagree with you and think DNSSEC is a viable PKI for their
intended use. These people want to use DNSSEC. We can give those people
an experimental RFC with OPENPGPKEY record, or we can force them to use
an individual submitted draft with a TXT record stalled until expiry.
Everybody resents that TXT records represent a grab-bag of items.

Stating your opinion that people should not use DNSSEC as a PKI is
irrelevant and these discussions happened in the late 90s. As a result
of those discusisons, there was a change made from SIG/KEY/NXT to
  RSIG/DNSKEY/NSEC records to limit those records to DNSSEC itself,
and leaving the model open for new RRTYPEs building PKI type structures
using DNSSEC. Such records have now included TLSA and IPsec. OPENPGPKEY
fits fine in this model.

Paul

---

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

> something like a Certificate Transparency project for DNSSEC data.

While that is on the horizon after the trans working group finishing up
their core bis document, your statement is not entirely correct.

Users have keyrings, and they can store keys previously seen or used in
their key ring. We are talking about end to end encryption without an
intermediate CA here. The CT model defends against bad CAs because TLS
clients don't log and store all EE certs of all TLS servers. But openpgp
users do keep the keys of those they send encrypted emails to in their
local keyring.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Sep 2015 16:21:38 -0400

> baked-ness that we expect of an internet standard.

I have already seen this experiment being used as an argument to drop
support for S/MIME roots in a root store.

The earlier projects that raised my concern were also 'experimental' or
otherwise outside standards track.

I have no problem with the draft going forward, provided that there is a
statement that I and other people making proposals can point to stating
that this is not going to block other approaches.

For example, if you have an organization that is hierarchical such as the
US federal government, the simplest way to deploy end-to-end email in the
organization would be to deploy a PKIX CA to issue S/MIME certificates,
store the certificates in a Web server [*] and stick the address of the web
server and the fingerprint of the intermediate KSK in a DNS record.

With this approach you have a separation in the service protocols that
matches the separation of duties in the typical enterprise. DNS is an
infrastructure that describes services, not an enterprise that describes
people.

[*] not a directory, not X.500, not LDAP, no a Web server that works and
does not require a $50,000 consult to configure it. X.500 directory was the
best wheeze the NSA ever had to sabotage PKI deployment and LDAP is just as
bad.

---

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

On Wed, 23 Sep 2015, John R Levine wrote:

> you get through DANE might be real or might be bogus.  What's the difference? 
> A key from DANE implicitly has an endorsement from the domain, but a key from 
> key servers can have endorsements via WoT signatures.  In each case. unless 
> you know the endorser, the endorsement is useless.

Again, once DANE confirms your keyid/fingerprint, you can still try and
find endorsements by pulling the key from keyservers, if you find you
need endorsements before encrypting it (and would not sent the email
plaintext otherwise)

The draft consists of a key lookup mechanism and a key fetching
mechanism. You keep insisting it is only a key fetching mechanism.

You can never solely pull a key from a keyserver and then use it, as it
is trivial to DOS the recipient by adding bogus keys to the keyserver
pools.

A key from DANE implicitly has an endorsement from the domain AND it can
contain further endorsements that the keyholder finds adding value.

Paul

---

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

On Wed, 23 Sep 2015, Phillip Hallam-Baker wrote:

> I have no problem with the draft going forward, provided that there is a statement that I and other people making proposals can point to stating that this is not going to block other
> approaches.

You mean a statement in the document? At the IETF?

The document makes no statement about any other mechanisms for encryption
or crypto key distribution.  I think that's the best we can do. If
people make weird statements about SMIME roots based on this document,
it should be pointed out those people are wrong.

> For example, if you have an organization that is hierarchical such as the US federal government, the simplest way to deploy end-to-end email in the organization would be to deploy a PKIX
> CA to issue S/MIME certificates, store the certificates in a Web server [*] and stick the address of the web server and the fingerprint of the intermediate KSK in a DNS record.

I strongly recommend those organisastions use draft-ietf-dane-smime and
publish SMIMEA records instead of OPENPGPKEY records.

Paul

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 23 Sep 2015 23:02:50 +0200

Paul Wouters <[email-masked]> writes:

>> Sure, but once again you're no better off than if you got the key
>> anywhere else.  I understand the argument for better key servers and
>> maybe better ways to discover key servers (a URI record should do
>> it), but I don't understand the argument for a whole new mechanism
>> with new security, scaling, and semantic problems.
>

Or they can use the already specified CERT record, which GnuPG supports.
Yes, CERT has its own share of problems, that you have explained, but I
don't see that any of the issues you brought up with CERT (that I mostly
agree with, FWIW) has had bearing on its deployment success or not.

/Simon

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Sep 2015 17:20:59 -0400 (EDT)

> Or they can use the already specified CERT record, which GnuPG supports.

You would still need to address the key lookup mechanism. One of the
reasons CERT failed for openpgp was the lack of binding between mailbox
and DNS. You did not know where to look for the CERT record.

> agree with, FWIW) has had bearing on its deployment success or not.

I agree. The lookup mechanism makes things like this possible:

apt-get install hash-slinger
openpgpkey --fetch [email-masked]

As well as running automatic encryption using the openpgpkey-milter with
postfix or sendmail. If you install openpgpkey-milter, your mail sever
will already encrypt all email sent to me.

Paul

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2015 18:00:17 -0400

>> I think this is OK. That's what you get for using a domain who
    >> does this sort of thing as your email provider.

    John> Right.  But again, if I'm trying to find your key, I have no
    John> way to know how sleazy your mail provider is, so I have no way
    John> to tell whether to trust the keys they publish.

Yeah, but  I believe for most users the only reasonable default for
things you get from the key servers is don't trust without additional
evidence.
For most users for most domains, I believe a reasonable default for this
dane record is trust if you otherwise would have sent plaintext mail.

    >> I do consider this proposal's handling of this case superior to
    >> the key servers.

    John> A key you get from the key servers might be real or might be
    John> bogus.  A key you get through DANE might be real or might be
    John> bogus.  What's the difference?  

It's all in the probabilities.
I'm making a judgment based on how I've seen PGP used over the last 20
years or so.
It seems like other people I believe to have used PGP a lot are making
the same judgment on this proposal.
Yes, that's appeal to authority.  

The only thing I can think to do beyond this is consider the sorts of
examples you're bringing up.
You think they argue that the key servers and this proposal are the
same.
I think they are interesting experiments that validate the utility of
this trust model in interesting cases.

    John> A key from DANE implicitly has
    John> an endorsement from the domain, but a key from key servers can
    John> have endorsements via WoT signatures.  In each case. unless
    John> you know the endorser, the endorsement is useless.

There we disagree.
I think implicit endorcement from the domain is valuable even if I don't
know much about the domain.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Sep 2015 01:24:45 +0200

> and DNS. You did not know where to look for the CERT record.

If I understand correctly, I believe section 3 of RFC 4398 discuss this:
http://tools.ietf.org/html/rfc4398#section-3

In particular section 3.3 explains how a OpenPGP key for
[email-masked] would lead to a CERT record on the
leslie.host.example domain.  See
http://tools.ietf.org/html/rfc4398#section-3.3

> will already encrypt all email sent to me.

That's cool!

It looks similar to GnuPG's auto-key-lookup mechanism which supports
CERT records.

/Simon

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Sep 2015 16:28:36 -0700

> things you get from the key servers is don't trust without additional

I'm confused by this thread.

I thought that the /essence/ of the PGP model was that the key servers
were merely convenient locations but /not/ 'trusted' locations.  That
is, all the validation and trust are based on object-related data and
not location-related.

d/

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2015 19:39:26 -0400

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

    Dave> On 9/23/2015 3:00 PM, Sam Hartman wrote:
    >> Yeah, but I believe for most users the only reasonable default
    >> for things you get from the key servers is don't trust without
    >> additional evidence.

    Dave> I'm confused by this thread.

    Dave> I thought that the /essence/ of the PGP model was that the key
    Dave> servers were merely convenient locations but /not/ 'trusted'
    Dave> locations.  That is, all the validation and trust are based on
    Dave> object-related data and not location-related.

Correct.
So, if you care at all about trust,  you then the trust you can assign
to a key just because you got it from a key server (approximately zero)
is very likely to be insufficient for any use to which you might like to
use that key.  So, you'll have to validate the signatures, consider
them, and think about object trust.

We're arguing about whether the implicit signature from the domain owner
raises the location-based trust enough above zero to be useful even if
you don't have prior knowledge of the domain's policies etc.

I think John is also arguing that he'd like to change the key servers to
have some location-based trust.  I'm sure I mostly don't want that for
the standard key servers, but something new that was sort of like a key
server but had some location-based trust might have some value.  We
might even call it a directory, even if we didn't use LDAP.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Sep 2015 16:50:15 -0700

On 9/23/2015 4:39 PM, Sam Hartman wrote:
> is very likely to be insufficient for any use 
...
> have some location-based trust. 

The current draft was essentially cast as 'merely' providing an
alternative venue for finding keys.  That's a distinct, useful function.

However it appears that some folk have conflated this other, deeper
function, of imparting trust to the key, using a model that is
fundamentally different than established OpenPGP practice.

It's fine to consider alternative models, especially when established
practice has a long history of failing to scale well.  What is not so
fine is having the model be promulgated with little-to-no consideration.

My own view is that task of finding keys should be treated entirely
independently of supplementing/replacing the trust model.  That means
the current work should consider DNSSec irrelevant and ensure that the
retrieved DNS records have utility equivalent to what it retrieved from
an existing key server.

d/

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Sep 2015 09:52:19 +1000

In message <[email-masked]>, Simon Josefsson writes:
> --=-=-=
> Content-Type: text/plain

Which is very much part of the problem.  RFC 103[45] have mbox names
which unfortunately causes namespace collisions.  Usernames and
hostnames shouldn't be in the same namespace.  RFC 4398 continues
to have that problem.

This draft and the s/mime draft address that issue moving the looked
up name out of the valid hostname namespace.

> --=-=-=
> Content-Type: application/pgp-signature; name="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBCAAGBQJWAzS9AAoJEIYLf7sy+BGd/7YIAIi/TxoHK9qEUPKdu33DocAu
> dWNa4WgN8hbeSRZ9v+w+ePACY6av++rfDFR+eXLWFjWKZCOD8/3P88cWh2qZydZ2
> l40TntWjuvkSgeXtpCeuDRTHyg3pD3bmx5pRUW7R+CMR3FE/CgK/BXBLRZDasqqM
> 2/ebSZSZdC2hwvN5ShVqXuwpuZtj/CHxqjfnUG5J3d65kgeoLN5rDZg/iYZ1egRG
> szGoGUI1SnljVMFUtIBxafSofgdisE8xINoJYs4TlKmuwz7dfnVUIg59AYu/FWss
> UXp+YdD0hAcbvyTCHNGW6OYVH9xONBvukYQCWZwDCXISHH/ravUk3PV5KGUYguc=
> =5uhn
> -----END PGP SIGNATURE-----
> --=-=-=--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 23 Sep 2015 20:14:03 -0400

> have some location-based trust.

If people thought it were useful, it'd be something to add, and it needn't 
be complicated.  For example, a keyserver could send signed probe messages 
with confirmation URLs to all of the addresses associated with the key, 
and add a signature that says "addresses all responded".  For that matter, 
if a domain wanted to sign its users's keys with postmaster@domain, why 
not.

Regards,

---

From: Tony Finch <[email-masked]>
Date: Thu, 24 Sep 2015 10:08:33 +0100

John R Levine <[email-masked]> wrote:
>
> A straightforward example is that the mail system, through malice or outside
> pressure, does an MITM attack on users who have their own keys, so it
> publishes a key it controls and re-encrypts mail on the way through to the
> user's own key.

The user should notice this since their encrypted mail will appear to come
from their mail provider not from the sender. (PGP signature doesn't
match 822 From:)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Sep 2015 13:40:35 +0200

> hostnames shouldn't be in the same namespace.  RFC 4398 continues

I don't see that as a problem.

To my knowledge, associating an OpenPGP key with a host is rare, and
when it happens the usual best practice in the OpenPGP world has been to
"invent" a email address like [email-masked] and put that in the
OpenPGP key.  So no collisions happen.

Even if a collision would happen, it is not a show-stopper.  You just
put two CERT records at the same name.  The client will need to have
functionality to figure out which key out of several to use anyway.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Sep 2015 13:42:43 +0200

> from their mail provider not from the sender. (PGP signature doesn't

Not really -- OpenPGP does not reveal anything about the identity of the
encrypting entity.  If the mail provider signed the email, it would be
noticeable, but there is no requirement to sign encrypted emails.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Sep 2015 07:49:45 -0400

On Thu, Sep 24, 2015 at 7:42 AM, Simon Josefsson <[email-masked]>
wrote:

> outside

Since PGP was invented, spam has become a major problem and worse. You can
have unrestricted end-to-end encryption without end-to-end authentication
but you can't risk using it.

Security requires a systems approach. There are very few cases where you
can get good security by adding one feature.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Sep 2015 13:54:09 +0200

> functionality to figure out which key out of several to use anyway.

Btw, how does draft-ietf-dane-openpgpkey handle OpenPGP keys for
hostnames?  I don't see anything in it.  I propose that
username<->hostname collisions for OpenPGP is a non-issue.

/Simon

---

From: robert <[email-masked]>
Date: Thu, 24 Sep 2015 08:02:54 -0400

I've sort of been following this discussion, not being too familiar with 
thinking about PGP. I did an S/MIME impl awhile back.

I would like to propose adding 2 features:
a. add a registry family that is self-signed and the members form a 
quorum for election and the family cert is distributed across many 
registries and there is eventual consistency.
b. use a blockchain to make eventually consistent and authenticate the 
quorum of members of a self-signed family cert, published to global 
registry.

I think you blockchain the self-signed, globally published family cert 
which contains quorum approval of additions and revocations of certs 
produced by this self-signed family cert with CA ability. I think that's 
secure without 3rd party CA/RevokeCertList (if IIIRC it's name).

Do you think my proposal has merit?

On 9/24/2015 7:49 AM, Phillip Hallam-Baker wrote:
>
>
> On Thu, Sep 24, 2015 at 7:42 AM, Simon Josefsson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Tony Finch <[email-masked] <mailto:[email-masked]>> writes:
>
>     > John R Levine <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
> Since PGP was invented, spam has become a major problem and worse. You 
> can have unrestricted end-to-end encryption without end-to-end 
> authentication but you can't risk using it.
>
> Security requires a systems approach. There are very few cases where 
> you can get good security by adding one feature.
>

---

From: Philip Homburg <[email-masked]>
Date: Thu, 24 Sep 2015 14:41:03 +0200

>noticeable, but there is no requirement to sign encrypted emails.

This can be solved by having the sender also sign the key used to encrypt
the e-mail. No idea how much work it is to add this.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Sep 2015 22:44:57 +1000

In message <[email-masked]>, Simon Josefsson writes:
> --=-=-=
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> >> >>> Some people disagree with you and think DNSSEC is a viable PKI for t=
> heir
> >> >>> intended use. These people want to use DNSSEC. We can give those peo=
> ple
> >> >>> an experimental RFC with OPENPGPKEY record, or we can force them to =
> use
> >> >> Or they can use the already specified CERT record, which GnuPG suppor=
> ts.
> >> >
> >>=20
> >>=20

People don't usually look at the set of hostnames before assigning
a user id and the reverse is also true.  Who gets change control
on the resulting domain name when there is a collision?  The user
or the host?

> functionality to figure out which key out of several to use anyway.

And what about all the other record types?
 
> iQEcBAEBCAAGBQJWA+EzAAoJEIYLf7sy+BGd3T0H/3zBklWxdB8p4b6SlW1XOgsP
> Omf9xVTsfxM5BawWHvhDHjum3pGL3JPbJbl1VGfeC0I3JCY9RUSzH3mI9Z4/2FgJ
> gkwwvTresagG7zeU46+Z0Btikd3sIN+EL1KWIlwjVPkH4Pncghoy6/PItCcPtzuS
> jU8l9+HQT+Y2OPNOTHAx6CGOh99UQSujvj0iafUbFug/U4hxbTzX1GHDS+m8xwxO
> 8taWkt9enul3spyRv1D/29Qoyus66snEWvPKQWYuwynToe2xxhmFjyUB8ocZAA1m
> zVtCmsGFNBbC2VYGJvpwHKms/CLwtkaWZBwQkEngte2N6JKRi4sBjmGHoSSRzZ4=
> =IuMd

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Sep 2015 14:56:20 +0200

> on the resulting domain name when there is a collision?  The user

When is this a problem?  Are you thinking of the conflict between
www.example.org and [email-masked]?  Why would that cause a problem?  I
believe it is highly unlike for their to ever be a OpenPGP key issued
for www.example.org -- and the practice in the OpenPGP community is to
issue such keys for [email-masked] instead -- so there shouldn't
be a conflict.  In any case, [email-masked] might have several OpenPGP
keys, so the client should be prepared to handle multiple records
anyway.

I'm likely missing something here.

/Simon

---

From: Paul Wouters <[email-masked]>
Date: Thu, 24 Sep 2015 09:33:44 -0400 (EDT)

> username<->hostname collisions for OpenPGP is a non-issue.

The key lookup part does not cover it, although of course the
OPENPGPKEy record is not limited to be at a <hash of lhs> location.

Per definition, hostnames in DNS can just be represented as hostnames
without hashing, so one could simply use:

mail.nohats.ca. IN OPENPGPKEY <blob>

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Sep 2015 10:05:30 -0400

On Thu, Sep 24, 2015 at 8:02 AM, robert <[email-masked]> wrote:

> a. add a registry family that is self-signed and the members form a quorum
> for election and the family cert is distributed across many registries and
> there is eventual consistency.

Take a look at this, it gives a mathematical framework for that sort of
approach:

https://tools.ietf.org/html/draft-hallambaker-prismproof-trust-01

The Meta Mathematical Mesh is intended to work in that way. Just finishing
some code and producing initial specs.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Sep 2015 07:15:29 -0700

> from their mail provider not from the sender. (PGP signature doesn't

Any security enforcement model that is based on having an end user
'notice' something is a model that will fail nearly every time.

d/

---

From: robert <[email-masked]>
Date: Thu, 24 Sep 2015 16:21:08 -0400

Philip,

I've been up some days now with a couple of kitten naps with lots on my 
plate.  Would you help me by providing a brief overview of the thesis, 
model and impl, please? It certainly sounds exciting with your modeling 
at the meta.

Regards,
Robert

On 9/24/2015 10:05 AM, Phillip Hallam-Baker wrote:
> On Thu, Sep 24, 2015 at 8:02 AM, robert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I've sort of been following this discussion, not being too
>     familiar with thinking about PGP. I did an S/MIME impl awhile back.
>
>     a. add a registry family that is self-signed and the members form
>     a quorum for election and the family cert is distributed across
>     many registries and there is eventual consistency.
>     b. use a blockchain to make eventually consistent and authenticate
>     the quorum of members of a self-signed family cert, published to
>     global registry.
>
>     I think you blockchain the self-signed, globally published family
>     cert which contains quorum approval of additions and revocations
>     of certs produced by this self-signed family cert with CA ability.
>     I think that's secure without 3rd party CA/RevokeCertList (if
>     IIIRC it's name).
>
> Take a look at this, it gives a mathematical framework for that sort 
> of approach:
>
> The Meta Mathematical Mesh is intended to work in that way. Just 
> finishing some code and producing initial specs.
>
>