By contrast, unsigned TLSA records offer essentially zero security.
If they're not signed, sure.
That's not what concerns me. What concerns me is whether all of those mail domains would permit such updates. This draft doesn't define an API for posting or updating such information, but we'd need one. ...
If they don't, they don't. People using those domains have to distribute their keys however they do now. I think you'll find that most people's mail either isn't forwarded at all, or goes through at most one level, with some sort of remote access to change where the forwarded mail goes.
Some mail domains are going to outsource every service that they offer. That's their decision to make, and for some mail domains it might well be more secure than trying to provide that service in house. The way AQRY is written at the moment, a mail domain can outsource its AQRY redirect server to a different party than its mail service provider, so it's not having to trust their MSP with their private keys. But any time that kind of service is outsourced, the customer almost inherently has less control over its private keys and less ability to prevent their exposure and/or misuse.
Yup. I think it's perfectly fine to define a way to let people run their own key servers, but I also think that if you require it, you might as well stop now because it's not going to work for enough people to be worth the effort.
One of my mail hosting clients is more or less an ad agency. They know a lot about the ad business and nothing about e-mail. If it were easy to use encrypted mail, they would, e.g., sending proofs to clients for campaigns for yet to be announced products. But there is absolutely no way no how that they will ever run a key server unless someone else, i.e. Tucows or me, runs it for them. I already know most of their passwords, because they trust me and it makes debugging stuff a lot easier.
I think that situation is far more common than the university or enterprise which has a skilled staff and a data center that can set up and maintain a key server and all of the necessary authentication goop. If they do, great, but you can't depend on it.
If the mail domain decides to outsource its DNS also (whether to you or anybody else), should it be automatically seen as extending that level of trust to its DNS provider, such that the provider can convincingly offer bogus information that's associated with an email address? I don't think so.
Since the DNS provider can already hijack all their mail, which means that these days he can get signed SSL certs in their name, I'd say that horse left the barn a long time ago.
Regards, John Levine, [email protected], Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
