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

[Daniel Kahn Gillmor <[e-mail]>]

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