On Tue 2015-07-21 12:25:35 -0400, Keith Moore wrote: > Of possible interest to this WG, or to the members of this WG, is > draft-moore-smtp-addrquery-01 > 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. > > Chris (my co-author) and I would appreciate feedback on this. > > https://tools.ietf.org/html/draft-moore-email-addrquery-01
I think this is a great start at a key discovery protocol that minimizes
metadata leakage. I note that a key discovery protocol does not need to
also be a key validation protocol.
The communications model in the draft supports this flow:
MUA <--> MSA <--> MX
since this is already the same communications model required for message
delivery, it is good for metadata minimization to piggypack on the same
channels for key discovery.
I think the arguments between Keith and Viktor about trusting the MSA or
not have to do with how we expect an MUA to validate the keys retrieved
by this mechanism. I would prefer to decouple that validation from the
discovery mechanism itself.
It's possible to discover a key/certificate for correspondent X that you
decide is unusable. That's an OK outcome, and one this draft should
accomodate. But i don't think that a user of this draft should have to
assume that any key/cert discovered by this protocol is necessarily
valid for the target e-mail address.
I've asked a couple other mail-interested folks about this, and one
suggestion i got back was that MXs supporting this draft should also use
TLS-wrapped SMTP on port 465. While port 25 is blocked outbound for
most users today, TLS-wrapped SMTP on 465 is not as widely blocked, so
this suggestion might make direct MUA <--> MX queries more feasible.
That said, direct MUA <--> MX queries potentially leak more metadata
than MUA <--> MSA <--> MX queries (in particular, (a) the MX learns the
IP address of the MUA in the former workflow, and (b) a popular MSA in
the latter workflow acts as a sort of low-latency mixing proxy).
I'd very much like to see something like this draft progress. If i can
help, please let me know.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
