On 07/22/2015 01:59 AM, John Levine wrote:
Here's my use model: I set up my online access account at bigbank, and
give them the address [email protected]. Then they fetch my
key and all the mail they send me is encrypted to my key.
I'm also thinking that we should avoid making the perfect the enemy
of the much better than we have now. In particular, although I think
it is important to make it possible for key distribution to be very
secure, we shouldn't insist on it.
Clearly this draft isn't insisting on "very secure", as it's relying on
TLS certs and the model that any trusted CA is trusted for all domains,
which is already known to have problems. But to me, using TLS certs
seems like a good compromise for now. They're somewhat secure and
reasonably well understood.
By contrast, unsigned TLSA records offer essentially zero security.
There are way too many ways to fool a client into accepting or caching a
bogus DNS response, and the typical DNS recursive server/proxy is
implemented in a consumer grade router that is itself woefully insecure.
(Also, I'm all for having DNSSEC-signed TLSA records as a second trust
anchor if both that and a x.509 TLS cert were required. I'm much less
enamored with the idea of a signed TLSA record being used instead of an
x.509 cert. I feel like that's a sideways step that's marginally
better for some use cases, but probably not an improvement overall.
It's replacing something that has well-understood limitations, with
something that has poorly-understood limitations. For instance, I'd
never trust a separate server to do DNSSEC signature validation.)
* When a message is forwarded, the mail system probably doesn't know
whether the message is being forwarded to the same person or not.
If the message was encrypted for the originally-specified recipient,
and that recipient has his mail forwarded to another recipient
address, should the forwarding address be able to read the mail or
not? The best (short) answer I have is "it depends". Ideally,
perhaps, the sender decides which address to use. (i.e. is this
"recipient's eyes only" or is it ok if the person to whom the
recipient has forwarded mail reads the message?)
You may be overthinking this. [...]
That's entirely possible. But I'd rather start by overthinking, than
to blindly assume that these issues don't matter just because they're
inconvenient to deal with.
* I assume that some mail domains are going to insist on seeing
messages in cleartext (maybe there's a legal requirement for
logging, or maybe they're worried about viruses), and are going to
either bounce or discard encrypted messages.
This part seems fine, I'm definitely OK with my broker's compliance
department reading his work mail.
* Related to this is a question of how email users configure their
address-related information, and to what extent they can do so.
Given that we're just making this up, I wouldn't spend too much time
working around hypothetical brokenness. The people I know have a
reasonably good idea of what their addresses are. It would be nice if
something could automagically update keys for every address, but if
they have to do it in two or three places, that's not a disaster.
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.
Even if we had such a standard, it's not clear to me whether most or all
mail domains supporting AQRY would support the update specification.
Also, you're a sophisticated mail user, so you can jump through more
hoops than the average user. I'm thinking about a user who has
multiple email addresses at multiple domains (typical), multiple MUAs
(also typical: work PC, home PC, home tablet, cell phone). Assume that
some of those MUAs support encryption and some don't (also a reasonable
assumption, I think, since it seems much easier to get a usable openpgp
plugin for a desktop MUA than for a mobile one). It's easy to say that
an MUA that supports AQRY should also be able to update the user's keys
and other info appropriately, but that MUA doesn't know about the user's
other MUAs and their capabilities.
There are mail systems that handle mail for tens of thousands
of customer domains, ...
The scenario that I had in mind was for the MSP to operate the initial SMTP
server, and for the customer to operate the redirect server (and the
customer would use its own cert for that server). But I do understand
that that won't suit all customers.
I have a bunch of customers whose mail is hosted at Tucows. I have
some control over their DNS, since I need to make the MX records
work but their web server is somewhere else entirely. They don't
have anything like a mail server, that's why they outsourced it to
Tucows.
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.
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. I don't think that a mail domain that contracts with a
DNS service understands that they're giving it the ability to spoof its
users' public keys and forwarding addresses and read their encrypted
mail, nor do I think that clients in general should treat unsigned DNS
records as sufficiently trustworthy for this purpose.
More generally, if the owner of a domain is already outsourcing email,
web, and DNS to different providers, should any of those providers be
axiomatically granted the ability to authenticate keys for users at that
domain? I rather doubt it. (Actually I was just making a note to have
the next version of the AQRY document recommend against using the same
domain name for either an MX or redirect SMTP server that is also being
used for a web server, because if you use the same domain name for both
you're effectively allowing your web server to authenticate AQRY
responses where you intended that or not.)
I think it's worth exploring use of JSON signatures to provide an
alternate means of authenticating results. However, I hope that we can
find a better way to verify those signatures than relying on TLSA
records, because I don't have faith that DNSSEC will be widely deployed
anytime soon.
Me neither (about half of my domains are signed, the other half aren't
due to no way to install the DS records), but we need something that
doesn't require setting up a special server just to distribute the keys.
I guess I've come to almost the opposite conclusion, which is that it's
a Bad Idea to trust any of DNS, web, or outsourced SMTP server, to
authenticate keys.
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
