Re: [saag] IETF 93 Agenda Request - Key Discovery

[Viktor Dukhovni <[e-mail]>]

On Thu, Jul 23, 2015 at 02:30:34PM +0200, Richard Barnes wrote:

> > Agreed.  It distributes mail information through mail servers, rather
> > than hoping one can keep mail servers and web servers synchronized.
> >
> > It's not perfect but the problems are fixable.
> 
> I'm kind of astonished that people still think that extending email
> protocols is a good idea for things like this.  For example:
> 
> "BASE64 is used to avoid the need for the server to produce JSON text
> which conforms to SMTP line-length restrictions."

SMTP line length restrictions are primarily a constraint on the
command side of the protocol.  The new command could be defined to
return lines of arbitrary length, but in practice it is much simpler
to in fact base64 encode the output.

> Why, in 2015, would we continue to choose modalities that come with
> these arcane restrictions?

Because email servers understand the email address namespace and
canonicalization rules.  Because email clients, already talk to
MSAs, which are well positioned to find the remote MX hosts.  The
MSA might even cache the responses for sufficiently "popular" email
addresses.

MX hosts already have code for connection and request rate limits,
which can be extended to apply to these new queries.  

Also for first-contact keys, the MX host would typically return
the mail server's public key, not the recipient's so it can continue
to offer spam and malware protection to the target user.  Real
end-to-end keys would often only be returned by the user in a reply.

Returning the MTA's key allows the MTA to return a public key
regardless of whether email address requested exists or not, just
return the same key for all inputs (there should also be one or
more per-user signature key digests along with that key, to verify
any end-to-end keys later sent by the user, which can be random
for non-existent users).

> Let's use modern technology for this.  What's needed here is
> request/response protocol that can carry JSON, not a store-and-forward
> protocol that carries an oddly constrained text format.  WebFinger
> seems fine.

The "store-and-forward" bit is irrelevant here, requests are not
for multiple recipients, nor are there keys for mailing lists.
Therefore, the envelope never splits, and there's no need to
commit data to a queue to ensure reliable delivery to multiple
destinations.

WebFinger requires email server operators to also deploy HTTP
WebFinger servers, or email servers to support an additional request
protocol.  Neither seems necessary.

-- 
	Viktor.