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

["John Levine" <[e-mail]>]

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.  Most of the PGP keys on my keyring
were collected from mail that people sent me or from keyservers, where
I am reasonably sure the key matches the purported owner, but I haven't
ever asked to see someone's passport.


>  * 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.  If I want people who send mail to one
of my addresses to encrypt the mail they send me, I'll publish an
encryption key for that address that I can decode, regardless of the
forwarding path in between.  The MTA doesn't have to know anything
about it, since (give or take the next issue) it'll just pass the
encrypted stuff through.  Similarly, if I plan to sign mail from an
address, I'll publish a signing key.  PGP at least makes it fairly
easy to attach and detach addresses to a key so you can publish the
key with only an address that matches the one it's published for (give
or take JOHN vs john vs john+bigbank.)

>  * 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.

>>  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.

>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.

R's,
John