On Wed, Apr 01, 2015 at 04:44:24PM -0400, Paul Wouters wrote: > On Wed, 1 Apr 2015, Nico Williams wrote: > >>And requiring the private DNS key is available on all name servers > >>for online signing really adds a huge amount of risk to the server > >>in case of compromise - an attacker could make up OPENPGPKEY records. > > > >Any dynamic lookup will have this problem. > > Not a non-dns based lookup that has no private DNSKEY ?
(Recall that we have a label suitable for doing a zone cut such that the SMIME and OPENPGP mappings are in their own zone, with its own signing keys. I expect operators to make that zone cut, and the I-D should recommend it, when the mappings are dynamic and require on-line private keys.) In both cases there are private keys which are used to protect just the mailbox->public key mappings and nothing else. The scope of compromise is the same in both cases. > > The pointer-to-server > >approach has the same problem, only at an HTTPS server instead of at a > >DNS server. > > Yes, in addition to not being able to tell an outage from an attack like > DNS with "indeterminate" or "bogus". DNS has that too (timeouts, SERVFAIL). > >The scope of compromise can be limited in both cases (since > >the online keys in the DNS case could be for just the SMIME/OPENPGP > >sub-zones). > > Those zones are the only ones that matter if you want to replace a PGP > key? I don't understand your point. You can't use compromise of a live-signed dynamic zone to compromise a parent or sibling zone that is not signed with the same keys. > >John L.'s regexp DFA concept doesn't have any such problems, > > I guess I still don't understand where this matching engine that returns > variable answers actually lives..... In the MUA. > >but I think it'd be rather slow for MUAs... > > Slow for MUA's and MTA's don't really matter that much. Some people > greylist for an hour. MUA UI latency matters a great deal. As for MTAs: they wouldn't be doing these lookups (unless you want your MTA to auto-encrypt to your correspondents when it can). > >Any mail domain that chooses simply not to implement any dynamic mailbox > >name canonicalization can fob off all normalization problems onto users. > > Agreed, but I still don't understand how using base32 in DNS helps that > draft at all. The QNAME either matches or not. You cannot return a DNS > record that does not match the QNAME/QTYPE. If we don't care to do anything other than exact matching then hashing works, but so does base32 encoding. A loss-less encoding makes it easier to deal with on the operator/ publisher side. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
