On Wed, Jul 01, 2015 at 04:54:30PM +0200, Kim Alvefur wrote:
> I kinda have a deployed implementation of this, for mutual server to
> server authentication with DANE in XMPP. I've settled on using SRV
> record indirection that would already be in place for srv-dane. This
> already has a number of deployments? and thus Just Works.
Only when we can expect the "client" to be a designated server for
a peer domain. Such symmetry is not present in SMTP, where outbound
SMTP servers are frequently different from the inbound servers for
same.
One might reasonably consider this pattern to not be DANE-based
"client authentication". Rather it is in a sense still server
authentication, with the accepting server using the original
connection to authenticate a reverse channel (as well establish
the identity of the client). So this is a very special case, and
indeed may be well suited to XMPP, but not otherwise generally
applicable.
> I experimented with something similar to the simple model in the draft
> before (_xmpp-server.example.com IN TLSA) but Matthew Miller (IIRC,
> can't find the thread now) raised an issue wrt delegation, that it gets
> harder to point at TLSA records hosted by a hosting provider.
The difficulty is mostly that SRV records can specify multiple
hosts, each with a separate TLSA RRset, but CNAME records from a
customer domain into a server provider domain can only point to
one TLSA RRset. If the SRV RRset points at just one server, there
is no difficulty, but when there are many, the client's asserted
identity needs to be that of the target server, not the hosted
domain.
Again for XMPP, since one is setting up a bidirectional channel,
one wants to know that the connection is between two domains, so
that messages in the reverse direction securely arrive at the right
place (no impersonation of other domains by clients).
For SMTP, one might grant a positive reputation or custom access
to an authenticated client, and if that's a provider, the reputation
or access control is properly that of the provider. With store
and forward, it does not make as much sense to think of the
communication as happening with the envelope sender domain.
> And it's
> harder to get people to deploy two sets of TLSA records at different places.
Still much easier than the initial cost of spinning up DNSSEC.
After that, publishing a few TLSA RRs is fairly cheap, and CNAMEs
can eliminate redudancy when the same end-entity keys (or same
trust anchors) are used in multiple contexts.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
