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

[Keith Moore <[e-mail]>]

John,

Thanks very much for the review.   Comments inline.

On 07/21/2015 06:12 PM, John Levine wrote:
>> Basically this is an extension to SMTP to allow mail exchangers to be
>> queried for information about the email addresses for which they accept
>> mail.
>> Such information could include public keys.
>> TLS is required by this extension and is used to authenticate the responses.
> This looks to me like a reasonable approach to distribute mail signing
> keys.  I have concerns about some of the details, but in general, it
> seems obvious that the way to distribute information about mail
> addresses is through mail servers.
>
> Concerns and niggles:
>
> For AQPX, I think it either needs a port number, or redefine it so
> that one AQPX follows the redirection chain and returns a response
> other than 213.  There are still plenty of firewalled environments
> that block everything other than port 443 and proxied port 80.
> (That's why I run ssh on port 443, and I'm not the only one who does.)
> I'm not too worried about malicious clients doing abuse by proxy,
> since the submission server knows who the clients are and a competent
> one has to deal with a range of client abuse issues already.

Hmm.   Maybe having a PORT option wouldn't be so bad.   I like that 
better than having AQPX follow redirects because that could take an 
arbitrary amount of time, and that seems likely to exacerbate timing 
hazards that already exist in SMTP.

> I fear that the response model is already too big, and we're likely to
> end up with servers that can serve keys just fine, nobody provides
> forwarding info (EXPN is still dead), and the other results are sort
> of random.  It's also not clear to me what the security model for
> transmit-signing-policy and the like are.  Even assuming we add a TTL
> to deal with stale policy advice, I don't see what I as the recipient
> of a perhaps unsigned message can usefully do with policy advice like
> "when-able" since I have no way to tell whether the other end knows
> what my policies are.

I agree that it's desirable to keep the response model small, and also 
understand that many sites are going to be reluctant to expose 
forwarding information.

Here's an attempt to summarize my thoughts on the matter:

  * 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?)

  * 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.
      o Such mail domains might, however, be willing to advertise a
        domain-wide public key for encryption use, and decrypt the
        message on behalf of their recipients after receiving it.
      o Mail domains that insist on seeing messages in cleartext, might
        or might not forward messages to other domains before that check
        is made.   The choice of which public key to use when encrypting
        (forwarded recipient's key or mail domain key of original
        recipient) depends on that.

  * Related to this is a question of how email users configure their
    address-related information, and to what extent they can do so.  If
    a recipient's MUA knows all of its user's addresses and can update
    all of his public key advertisements, that's one thing.   It might
    be relatively easy for users to manage their address-related
    information (including public key advertisements) if that's the
    case.   If some of those mail domains don't let users update their
    address-related information, that's another thing.   But I assume
    that the latter will be fairly common.

  * Another wrinkle: if the keys advertised via this mechanism are in
    their usual formats (e.g. openpgp or x.509v3 certs), the associated
    email addresses will be attached to the keys.   So if
    [e-mail] wants to forward his mail to [e-mail], is it
    okay if the key advertised at [e-mail] says [e-mail]
    instead of [e-mail]?   (probably not, though at least openpgp
    key files can have multiple aliases)


I'm hoping that a simple model that handles all of these cases (and 
probably some others) can be found.   So far, I haven't found it, but I 
haven't been looking very long.

Anyway, I think getting the data model for responses right is the 
hardest part of this.

>
> In section 6, the requirement that the TLS session has a certificate
> with the same domain as the address in the response is unlikely to
> work.  There are mail systems that handle mail for tens of thousands
> of customer domains, and it's hard to imagine them maintaining tens of
> thousands of certs to serve up with SNI.  I don't think this is
> particularly hard to fix, perhaps the customer can provide the
> relevant part of the JSON signed, and publish the signing key in a
> TLSA record at _aqry.<domain>.

This is one of the reasons for the redirect capability.   If the initial 
SMTP server is returning a redirect, then its cert only has to be valid 
for the domain name that appears as the target of the MX record (or the 
address in the response if that happens to be the case).   So an initial 
SMTP server doesn't need to have tens of thousands of certs, if it can 
return a redirect to a server that does have an appropriate cert.   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 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.   With all of the limitations on PKI and server certs, at 
least enterprise network admins understand by now how to obtain them.   
(Whether they understand how to properly safeguard their private keys 
is, of course, a completely different question.)   But the learning 
curve for DNSSEC is much steeper, and there's much less mindshare around 
it.

(If I had been willing to assume DNSSEC deployment, I would have said 
that a DNSSEC-signed MX record for the address's mail domain, + a TLS 
cert for the MX target were sufficient for a AQRY response to be 
trustworth.)

>
> I want to emphasize that these concerns all look straightforward to
> fix and the basic idea is well worth working out and trying out.

thanks again,

Keith