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

[Viktor Dukhovni <[e-mail]>]

On Thu, Jul 23, 2015 at 05:54:20PM +0200, Richard Barnes wrote:

> > My MTA already knows where it routes that address and can find the
> > appropriate account and the corresponding keys.  Webfinger or anything
> > else would either need a side channel into the MTA or try to match the
> > local address resolution logic.  Ugh.
> 
> Consider the security requirements.  The MUA needs to know that it's
> got the authentic address/key binding, where the address is the one
> the user put into the MUA.  So if it's going to talk to an MTA, it
> needs to be the REMOTE MTA.  If it reaches that remote MTA through its
> local MTA, that's a problem, since now either (1) the MUA has to trust
> the local MTA for all of its keys or (2) the remote MTA needs to sign
> its address/key bindings.  Both of which are gross.

The MSA authenticates the requestor, which is not something the
remote WebFinger server can do, and might be required to authenticate
itself to the remote MTA (Shumon Huque and I are proposing extending
DANE TLSA to client auth).  This will help reduce abuse vectors
for the key lookup service.

Recall that the party managing the MSA is generally also the party
managing the Inbox, and can supply MiTM keys to the user's
correspondents.  Reading the reverse traffic is often sufficient
to recover most of the forward traffic.

In the simplest model, the MUA will need to trust its MSA as an
introducer of said keys.  Just like Webmail clients trust the
javascript email application engine from the Webmail provider.
Just as the MUA would have to trust the WebFinger server, and
whatever sources that server consults to vend the keys.

Note that keys will be exchanged via ongoing email traffic, not
just initial contact.  The MSA's role will then be mostly as a
proxy to confirm the freshness of those keys, and lying about that
would be distruptive and rather noticeable.  Tamper-evidence is
likely to deter the majority of attacks.

It is of course also possible to specify that the protocol preserve
remote signatures across the MSA proxy, along with the appropriate
DNSSEC RRs to authenticate those signatures.  I am just not sure
it is worth it.  Injection of MiTM keys is difficult to do
undetectably.  Security savvy users can always check fingerprints
via additional channels, plus see above comments on ongoing traffic.

--
	Viktor.