Subject: [dane] Looking up keying for the client.

From: Warren Kumari <[email-masked]>
Date: Wed, 9 Jul 2014 12:28:37 -0400

Dear collages

Enabling a server to look up keying information for the client was
raised as a possible feature during the charter discussions.

This is a call for discussion on "how to do” / “is this possible / advisable”.
If there is sufficient progress in in the next week the chairs would
like to dedicate some time at the meeting in Toronto to this topic.

The goal of this discussion is to
1) gauge if this possible / desirable,
2) find environments that would like full authentication of both parties.
3) evaluate different ideas on how proceed.

        Olafur & Warren

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Jul 2014 12:44:20 -0400 (EDT)

> 3) evaluate different ideas on how proceed.

The Libreswan Project uses a local DNS server plugin, and piggybacking
on the cache management to do IPSECKEY lookups. Setup IKE/IPsec when you
find a new key that wasn't in the cache yet.

Paul
(unbound python plugin)

---

From: James Cloos <[email-masked]>
Date: Wed, 09 Jul 2014 15:31:07 -0400

The primary issue is where to find the tlsa.

For oob, it will have to be based on whatever autentication info which
the initiator provides to the listen(8)er at the application level.

For x509 certs, there are several additional possibilities.

The CommonName (CN) field often has either a dns name or something which
looks like an email address.  But it might also be an actual, real-world
common name.

The Subject Alternative Name can have a set of dns names, email addresses,
URIs, IP addresses, et cetera.

The appliation might ask for a specific association when an application-
layer authentication is used or tried.  Or may tell the tls code to
prefer email, dns or whatever names.

Converting the selected string to a lookup needs specification for each
type of string.

For dns names, we could specify an indentity transformation, or add a
simple prefix, such as _client, _$ProtoName._(tcp|udp|etc) or _$ProtoName.
The prefix SHOULD NOT involve port numbers.  That is appropriate for a
listen(8)er on a well-known port or found via SRV or the like, but not
for initiator tlsas.

For email-like strings, we should specify the same transformation we
specify for smime.  The current draft looks mostly OK for that, but
an _at between the h(H(left)) part and the right part may be in order.

For URIs like $proto:$hostname or $proto://$hostname, a lookup like
either _$proto.$hosname, _$proto._client.$hostname seems reasonable.

For URIs like $proto:$email or $proto://$username@$hostname either
following the email transformation or adding an additional _$proto
before the results of that transformation seems right.

All of 0,1,2,3 should be OK if the intitiator sends a set of certs,
but the EE cert SHOULD be the one used to find the tlsa set.

The OOB case should follow the same advice as for OOB listen(8)ers,
wrt types of tlsa.

IP address SANs should map to where the ptr is, provided it matches the
IP from which the socket originated.  And even without an explicit IP
address SAN, the originaing IP probably SHOULD be checked.  A prefix
in that case probably is unneeded; the tlsa can be parallel to the ptr.

Other types of SAN data probably need their own RFC to map to tlsa
locations.

CNs probably should be checked only as a fallback, if it is different
from any of the SANs and if none of them worked.

The application SHOULD get to know exactly which SAN/CN verified, so
that it can match that to its ideas about aaa.

I think that is everthing I've been considering recently.  (I had
planned on a missive about this; but the above is written from memory,
with minimal editing.)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 9 Jul 2014 23:44:55 +0000

> Dear collages

Auto-corrupt?

> This is a call for discussion on "how to do? / ?is this possible / advisable?.

For SMTP, the plausible use-case is that the client's EHLO name is used
to construct a TLSA lookup key, something along the lines of: 

	_smtp-client.${ehlo_name} IN TLSA ?

which then *could* make it possible for the server to obtain key material
to authenticate the client (request client certs when TLSA records are
found, ...).

A serious difficulty is that even legitimate clients with non-negligible
frequency use bad EHLO names, for which DNS lookups tempfail.
Since timeouts due to bad input cannot be distinguished from timeouts
due to transient network problems, client DANE TLSA authentication
cannot be reliably applied opportunistically (zero configuration).

This is likely OK, since client authentication is perhaps only
useful when the client domain is whitelisted or otherwise already
known to the server.  Authentication of a stranger domain has rather
limited utility.

So I can see SMTP client authentication with DANE serving some
limited use cases, for example, relay access via a provider's
outbound gateway (for MTAs, not submission).

So the main task is to identify sensible use-cases, then define
associated lookup keys and lookup error handling for each use-case.

-- 
	Viktor.