Re: [Uta] draft-moore-smtp-addrquery

[Keith Moore <[e-mail]>]

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 [e-mail].  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