Subject: Re: [dane] draft: Client Certificates in TLSA records

From: Kim Alvefur <[email-masked]>
Date: Wed, 01 Jul 2015 16:54:30 +0200

Hi,

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.

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.  And it's
harder to get people to deploy two sets of TLSA records at different places.

¹ https://xmpp.net/reports.php#dnssecdane
-- 
Kim "Zash" Alvefur

---

From: Shumon Huque <[email-masked]>
Date: Wed, 1 Jul 2015 11:25:02 -0400

> already has a number of deployments¹ and thus Just Works.

Yup, I think that's a viable strategy for XMPP s2s authentication, where
there are symmetrical characteristics on both sides in the form of SRV
records.

In the general case of client authentication (which our draft covers), this
is probably not true. For example client systems may not have stable
network addresses or associated address records, and might generally be
moving around the network. In such cases, they need to relay their identity
to the server side. Section 7 of our draft does talk about application
protocol specific behavior that might take into account other client
characteristics where available, but defers those details to application
specific documents to define.

-- 
Shumon Huque

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 1 Jul 2015 16:50:50 +0000

On Wed, Jul 01, 2015 at 04:54:30PM +0200, Kim Alvefur wrote:

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

> 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

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.