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

[Richard Barnes <[e-mail]>]

On Thu, Jul 23, 2015 at 3:05 PM, 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).

I don't know why you think MXs or MTAs have any role in this at all.
The major point of this stuff is to look up keys for e2e, so it's most
likely to be implemented in MUAs, most of which either already have an
HTTP stack (to support HTML email), or are web pages themselves.  If
you want to add this to a web mail client, here's your implementation:

function getKey(uri) {
  var xhr = new XMLHttpRequest();
  xhr.open("GET", makeWebfingerURL(uri), false);
  xhr.send();
  var jrd = JSON.parse(xhr.responseText);
  return jrd.properties.keys;
}

It's not that many more to add it to Thunderbird.  How many lines of
code do you want to add to your MUA?


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

That is only necessary if you want to make keys discoverable for your
users.  And it's probably easier than upgrading your MTA to support
some new thing.

--Richard


>
> --
>         Viktor.
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag