Subject: [Danish] Application-Independent Client Identity through DANE

From: Rick van Rein <[email-masked]>
Date: Thu, 01 Apr 2021 10:17:28 +0200

Hallo Danish,

I was happy to learn that Client DANE is being worked on again.  An
opportunity that I'd like to see addressed is a mechanism for clients
to state that their identity sits under a given domain.  The way to do
that now involves LDAP, protected with TLS and DANE/DNSSEC.  There are
advantages including simplicity about doing this with Client DANE.

Would you consider the attached portion of text?  It would be a way of
achieving Realm Crossover, our globally described intention in
draft-vanrein-internetwide-realm-crossover

The general approach is to use DNSSEC-based authority for domains, and
treat the assignment of userids as the prerogative of the domain, to be
validated over a secure backlink.  The draft expired just yet, and I'd
love to update it with a reference to the following in Client DANE :)

Thanks for considering,

Rick van Rein
InternetWide.org / OpenFortress.nl

2.0.  Format 0: Application-Independent Client Identity

   The purpose of this format is to allow clients to
   state [client-user-identity]@[client-domain-name] style
   identities which are not tied to any specific application.
   This uses certificates to implement Realm Crossver
   <xref target="draft-vanrein-internetwide-realm-crossover"/>.

   In this format, domain users hold certificates signed
   under a CA certificate that is approved of in a TLSA
   record named

   _client-identity.[client-domain-name]

   The TLSA record SHOULD NOT set the TLSA RDATA field for
   Certificate Usage to match end entity certificates.

   The issuing CA or CAs approved by this statement MUST NOT
   issue any attributes that represents another domain name
   than [client-domain-name].  Note that a sequence of
   "domainComponent" or "dc" RDNs would combine to form a
   domain name.  Note that a domain name may occur as part
   of a longer attribute.

   The issuing CA or CAs approved by this statement SHOULD NOT
   issue any attributes that represent a user identity that
   has not been established by a RA run under control of the
   domain [client-domain-name].  Note that a userid may occur
   as part of a longer attribute.

   To implement these rules, the issuing CA or CAs approved by
   this statement MUST NOT produce attributes of which it does
   not known whether it represents a domain name and/or user
   identity.

   On the grounds of this TLSA statement, the relying party
   SHOULD NOT trust any other information than domain names
   and user identities.  This does not preclude that other
   paths may validate the information, possibly including
   application choices to treat attributes as informative
   suggestions without security implications.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 02 Apr 2021 08:33:42 +0200

Hello Danish,

Shumon suggested that the text I wrote might be too specific
for an application that I have in mind.  This is an alternative
text aiming to say just enough to support meaningful conclusions.

I mention "uid" and "dc" attributes as a hint without force.
This may be helpful to provide some guidance to allow various
applications to come together.

Cheers,
 -Rick

   The purpose of this format is to certify client's
   [client-user-identity]@[client-domain-name] style
   identities without ties to any specific application or
   protocol.  This is a mechanism to support Realm Crossver
   <xref target="draft-vanrein-internetwide-realm-crossover"/>.

   TLSA records with such names SHOULD NOT set the RDATA field
   for Certificate Usage to match end entity certificates.

   The issuing CA or CAs approved by this statement MUST NOT
   publish certificate attributes whose meaning specify the
   [client-user-identity], the [client-domain-name] or any
   parts or combinations thereof, except when (1) the full
   [client-domain-name] is represented and (2) that domain has
   approved the [client-user-identity] and the public key to
   belong to the requesting client for at least the period
   of validity of the certificate to be issued.

   After extracting the [client-domain-name] from a client
   certificate and validating the certificate to comply to
   this TLSA record, a relying party can trust attributes
   that specify the [client-user-identity] such as "uid", and
   the [client-domain-name] such as in a "dc" sequence, to
   adhere to the authoritative hierarchy of Internet names.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 2 Apr 2021 08:44:41 -0400

Thanks Rick,

I'm reviewing, and hope others will too.

I'll note that although this work is expected to be done in the context of
an IOT focussed working group, the DANE client authentication draft is
general purpose in nature, and we know that there are several folks from
other application communities interested in this (SMTP, etc). So, I'm
personally very open to expanding the utility of the draft to your Internet
identity proposals, and adding another proposed format to support
application independent identities sounds quite reasonable to me. Will
circle back with more detailed comments soon.

Shumon.

On Fri, Apr 2, 2021 at 2:34 AM Rick van Rein <[email-masked]> wrote:

> --
> Danish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/danish
>

---

From: Rick van Rein <[email-masked]>
Date: Sat, 03 Apr 2021 08:45:04 +0200

Hi Shumon,

Looking forward to your comments.

> [...] we know that there are several folks from
> other application communities interested in this (SMTP, etc).

There are several concrete ways in which Realm Crossover could lighten
the burden of SMTP spam.

 - Clients could submit directly to the destintation SMTP server
 - Clients could run a personal destination SMTP server (P2P style)
 - Submission services could work with less configuration

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Sat, 03 Apr 2021 08:46:04 +0200

Hello Ash,

Thanks for thinking along!

> I'm especially interested in the name formation, and how you see that
> fitting in with your protocol.
>
> Here's a broad pattern for your consideration:
>
> _servicename.identityname._identitytype.domain
>
> _servicename is optional, and indicates that an identity exists as one of
> multiple sub-identities of an entity. Examples of this might be
> _verification, _encryption, _ldapclient, etc...

When you say _verification or _encryption you are being general; this
should also have an _authentication tag to login users from a foreign
domain ("Realm Crossover", draft-vanrein-internetwide-realm-crossover).

However, _ldapclient would be one application protocol.  That is what I
want to avoid, but I agree some may prefer it.  The DNS * wildcard may
help out here.

Your _servicename looks to me like two things,

_protoname._cryptotask

where (terse forms of) _encryption and _verification and _authentication
may occur as _cryptotask and _ldapclient or * could be the _protoname.
The * would allow domains to state generic application support.  It may
even be an idea to allow one * for both these.

> identityname is the unique identifier for the identity, within the scope of
> the identity type for the domain. This could be multiple labels
> representing the serial number and model of an IoT device, or a hash of the
> local part of an email address, as described in
> https://tools.ietf.org/html/rfc8162

Here we differ.  I would prefer to not mention the user identity, in any
form, because you end up making things static and iterable.  We've
investigated DANE in SURFnet.nl and concluded that there were too many
involved parties to consistently keep it up (without automation, which
is far from trivial) and adding user identities does not help.  It also
means that adding users takes time.  This includes adding temporary
users (to address a frivolous webshop) or other creative forms that
people may think of, and would get frustrated by this.  DNS caching
times suddenly become a nuisance, operators would set it low and DNSSEC
would have to work much harder.  So, my guess is that mentioning users
in DNS will never get traction.  Devices are different in this respect.

This is why I proposed to reference a CA instead.  Certificates can be
issued by a fixed party, but retain dynamicity as long as the CA is
dynamic (which is feasible when DNS does not need to change).

> _identitytype serves multiple purposes. It provides a human-friendly means
> of indicating the type of entities which are represented under this part of
> the DNS hierarchy. It also provides a delegation point, so that the group
> responsible for managing those identities may be limited to managing just
> those identities. We think that this is useful because the people and
> systems responsible for managing IoT device identities in DNS will
> typically not be the same people and systems that manage the DNS records
> for the organization's websites or email configuration. An example of this
> might be _device, _smimecert, _smartcard, _hardwaretoken, etc...

Basically compartmentalisation of the name space for purpose.  Yes, I
can see that work.  It does mean that applications need to register
their use but, it being a mere name, I could imagine registering it
loosely, suggesting the "Specification Required" level, where an I-D
would suffice.

Let's say I called this CXOVER, for Certificate-based Realm Crossover,
then I'd register "_cxover" as a label.  I could write a spec if that is
helpful, we then have something concrete to battle about.

> domain is any number of labels, including the organizational domain.
>
> The TLSA record can definitely be used to convey a CA certificate, so I
> think that you can do what you need to without modifying the record format.
> Does the naming pattern described above fit with your use case?

It's close, but I have some proposals.  What I end up with, after adding
your ideas above, would be

_protoname._cryptotask._identitytype.domain  IN TLSA  ...

with examples like

_smtp._authn._cxover.example.com.  IN TLSA  ...
*._authn._cxover.example.com.  IN TLSA  ...
*._cxover.example.com.  IN TLSA  ...

Note: _authn and _cxover seem to be saying similar things here.

Curious what your feelings about this are.

Thanks!
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Sun, 04 Apr 2021 11:54:15 +0200

Hi,

> helpful, we then have something concrete to battle about.

I played around with ideas and wrote draft-vanrein-cert-xover.  I don't
know exactly how it'd connect to Client DANE, many ways could work, but
I now have a clear mind on what is required:

 - a general label like _cxover should have clearly defined meaning
 - that way, everyone would know the basis of trust
 - Realm Crossover has no other trust basis and needs clear semantics
 - cryptotasks _decrypt, _login, ... are likely generic to Client DANE
 - this could work by registering the _cxover name with IANA
 - the registration would point to the specification of trust

Am I closing in on your idea of generic/specifc separation, while
preserving the semantics needed to decide on trust matters?

Cheers,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Tue, 06 Apr 2021 11:11:33 +0200

Hello Ash,

> This is interesting. So, let me summarize what I understand so far: this
> provides a way of conveying an organization's CA so that any sub-identity
> may be authenticated without explicitly creating a record for every
> sub-identity in DNS. Is my understanding correct?

Yes.  Although I barely focus on finding certificates, as I am assuming
a rich user or server environment.  It's interesting though.

The central idea is to trust a domain on the basis of (root or
intermediate) CA certificates in DANE; they might be stored or hashed in
DNS.

> Here's an overlap (maybe): In the PKIX-CD draft (
> https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd/) we present a
> method by which an authenticating entity may use the EE's DNS name and AKI
> (both found in the certificate) to construct a URL for discovering the CA
> certificate.

That is an interesting idea, and perhaps not specific to client DANE.  I
would venture to guess that it solves a general problem, possibly even
of finding a root CA that may be solely trusted on grounds of DANE.  I
was lazily proposing to put whole certificates into DNS, perhaps even
for intermediate CAs.

> Even if you don't publish the EE certs for DNS-based identities in DNS, you
> can still use DNS to discover the trust chains. You can still get the DNS
> name or email address out of the presented certificate and use that with
> the AKI to construct a URL where the intermediate certificate that can
> verify the EE certificate should be found.

Yes.  This is also a way to get away from a large-but-limited set of
well-known CAs, so it might help in applications that are more diverse,
such as a domain-local CA or even peer-to-peer networks that employ DNS.

> If this pattern works for your use case, then you'll have some
> cross-compatibility for other use cases, where we do need the certificate
> to be discoverable in DNS (object security use cases) as well as having a
> sort of transitional mode between traditional PKI and DANE for
> authentication, both hinging around DNS names for entities.

I think it *almost* works.

Your "_device" is an example of an identity grouping label, but it is
not clear to me if this is something that is formally registered or a
local network choice.

When formally registered, a specification could be attached that defines
the semantics of that name.  As a consequence, it would be possible to
visit completely foreign domains for the first time to discover what
their certificates are saying.  The shared semantics are the pivotal
point here; applications need to know what they can assume when they
find such a label.  This is a reason why SRV records work so well, yet
are flexible for new specifications to adopt.

It would be possible to make a choice to trust only configured domains
to set a configured _label.  Then, anyone can add names without
formalities, but a label _client-identity would not have necessary
meaning; the domain owner would not be expressing anything but data,
with no necessarily implied meaning.  So this idea of registered naming
is vital to the idea of Realm Crossover.

The ideas of with/without semantics can both be used with a _label that
says "make no assumptions, unless you were configured to look underneath
this one".

Can you elaborate on that please?

Cheers,
 -Rick

---

From: Ash Wilson <[email-masked]>
Date: Wed, 14 Apr 2021 11:47:16 -0700

Hi Rick,
Sorry to keep you waiting on a reply.
I agree with you that we will need a registry of identity grouping
labels, if the construct does not fit within another existing registry.

The use case for discovering CA certificates makes sense to me, and with
such a mechanism, you can simplify the use of private PKI for establishing
TLS sessions. Having an underscore label representing the client identity
type, immediately to the left of the identity grouping label, could fit for
generic discovery of CA certificates via TLSA records, secured by DNSSEC.
This sounds like it would require a change in how TLS works, and for this
case we will also need a registry of client identity types. But I think
this might work, and it doesn't necessarily need to carry the complexity of
the PKIX-CD discovery pattern as long as you have DNSSEC configured for
your zone.

What are your thoughts on signing and encryption for object security use
cases? How do you see entity certificate discovery happening?

-Ash

-- 

*Ash Wilson* | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Rick van Rein <[email-masked]>
Date: Tue, 20 Apr 2021 10:57:55 +0200

Hello Ash,

> labels, if the construct does not fit within another existing registry.

I hadn't checked if a suitable registry already exists, but the
"Underscored and Globally Scoped DNS Node Names" could be it, because
RFC 8552 defines it as just what I had in mind.

https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Note that these are "static" _labels, defined under Expert Review, to be
assigned structure/semantics while at it, which is what I meant.  These
are not "dynamic" _node123 labels that could be defined by clients,
though that would be possible under a static _label too.  I am not sure
what you are looking for.

> generic discovery of CA certificates via TLSA records, secured by DNSSEC.

Yes, that's a nice and terse summary of what I have in mind.

> This sounds like it would require a change in how TLS works,

Not the protocol, but the trust evaluation.  It's not that different
from server DANE applications though.  In fact, trust in a client/peer
certificate is often defined locally.  One of those local definitions
could be to adopt the "CXOVER" or "Certificate Crossover" mechanism.

> and for this

This is not mine to judge.

> cases?

Before you mentioned sigverify and encrypt, which are the pivotal points
where trust is needed.  I'd say that the technical operations with these
names are not what users need; they need to use them in protocol
settings for purposes: authentication, integrity validation, and indeed
from-here-to-recipient privacy.

> How do you see entity certificate discovery happening?

Ehm, use cases...

1. TLS clients would transmit the identity that the want trusted.
   The other TLS peer retrieves the uid=,dc=,dc= from the certificate
   and does a TLSA lookup for the dc=,dc= domain to validate the CA
   and trust the uid=,dc=,dc= remote TLS client.

2. S/MIME signatures https://tools.ietf.org/html/rfc5652#section-5.1
   intends for signerInfos-mentioned certificates to be contained
   in the certificates set.  Validation retrieves the uid=,dc=,dc=
   from the certificate and does a TLSA lookup for the dc=,dc= domain
   to validate the CA and trust the uid=,dc=,dc= sender identity.
   S/MIME signatures intend to include the certificate chain.

3. S/MIME encryption https://tools.ietf.org/html/rfc5652#section-5.2
   is cryptographically initialised by the sending party, so this is
   the case that requires download of certificates.  To validate the
   certificate retrieved from such a download, the uid=,dc=,dc= in
   the certificate is verified against the intended recipient and
   then the sender does a TLSA lookup or the dc=,dc= domain and
   validates the downloaded certificate can be trusted; it then sends
   S/MIME content which intends to include the certificate chain(s).

For downloading in 3, I tend to prefer the standards' prescribed choice
of LDAP because of its rich semantics.  For small devices there may be
other considerations, but they are likely to be less rich, and so not a
general solution.  (BTW, I have made a very small LDAP stack too, but to
date it has only been unit-tested.)

Inviting opinions :)

Cheers,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Tue, 20 Apr 2021 11:08:53 +0200

Ah,

>> How do you see entity certificate discovery happening?

Have you seen RFC 4386?  (New to me.)

There's no _COAP prefix yet, which might be helpful for IoT.

-Rick