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
[email protected] wants to forward his mail to [email protected], is it
okay if the key advertised at [email protected] says [email protected]
instead of [email protected]? (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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
