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

[Phil Hunt <[e-mail]>]

Phil

> On Jul 23, 2015, at 15:05, Viktor Dukhovni <[e-mail]> wrote:
> 
> 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.

I wonder of this is true (not wanting http) for those supporting the oauth sasl extension. 
> 
> -- 
>    Viktor.
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag