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