>>>>> "AS" == Andreas Schulze <[email protected]> writes:
AS> just to make sure I read above right:
AS> - $client connect from $random_highport to $server:$fix_serviceport.
AS> - $server extract $client_ip and lookup $client_name (PTR)
AS> - $server lookup $fix_serviceport._clientauth.$client_name. for TLSA Record.
Unfortunately unnecessary constraints on the ptr zones are too common to
support sticking tlsas therein.
Client tlsa probably will only work for protocols where the client
claims to be something which can be forward-resolved, such as smtp (helo
name), sip (From: address) or the like.
When clients claim a name which looks like a hostname, the tlsa lookup
could be as simple as:
_$PROTO._clientauth.$CLAIMED_NAME
The tls cert is likely in such cases to offer $CLAIMED_NAME as CN or
within the dnsnames.
Whether $CLAIMED_NAME is related to the remote ip address is a separate
issue which, if the server checks, can be used as part of the trust
equation. Just like the current case with mta->mta smtp client certs.
For things like sip, where the claimed name usually looks like an email
address, the left hand side probably ought to be hashed and hexed, as
per the dane drafts for smime and openpgp, and included in the lookup.
The exact query for that case should get some discussion.
Again, whether the remote ip address looks reasonable for the claimed
name is orthogonal to what the cert claims to certify and whether the
tlsa provides a trust path for said cert. But also again, servers can
use multiple data sources to decide how much they trust any given
credential.
Alternatively, the server might get the claimed name from the offered cert.
Either way, and unlike the server tlsa case, $PROTO should be a name
rather than a port number. The string should derive from whatever means
led the client to the particular server, such as the protocol specified
in a uri, used for a srv lookup, the keyword in iana's port-numbers
registry, et cetera. (Which wins in case of conflict?)
-JimC
--
James Cloos <[email protected]> OpenPGP: 0x997A9F17ED7DAEA6
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
