--On Thursday, September 17, 2015 11:23 -0400 Sam Hartman
<hartmans-ietf@xxxxxxx> wrote:
>>>>>> "John" == John C Klensin <john-ietf@xxxxxxx> 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(example-2@xxxxxxxxxxx.) IN CNAME John>
> transform(example@xxxxxxxxxxxxxxxx.) 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.
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.