[Dance] Comments on draft-ietf-dance-architecture-09

[Eric Rescorla <[e-mail]>]

Document: draft-ietf-dance-architecture-09.txt

I am sorry for the very late review on this. It only came to my
attention recently when looking at the IESG agenda. I have some
detailed comments below, but my overall impression of this
architecture is as a solution looking for a problem.

The document lists out a very large number of use cases where this
technology might be used, but doesn't really show any evidence that
the WGs and organizations where those use cases apply actually are
interested. This is already a bad sign, but I find it even more
concerning that when I look at the use cases I know well (mTLS for
HTTPS, WebRTC, SIP), the treatment is very shallow and doesn't seem to
reflect an understanding of the real deployment challenges that exist
in these environments. I'm very skeptical that this technology would
in fact be very useful in any of these cases.

It's certainly possible that there are settings in which this
technology would be useful, but I don't think this laundry list of
potential applications is at all helpful. Instead, this document
should be pared down to the specific use cases where WGs or
vendors/operators/etc.  are actually prepared to deploy something like
this.

DETAILED COMMENTS
S 1.

   A digital identity, in an abstract sense, possesses at least two
   features: an identifier (or name), and a means of proving ownership
   of the identifier.  One of the most resilient mechanisms for tying an
   identifier to a method for proving ownership of the identifier is the
   digital certificate, issued by a well-run Certification Authority
   (CA).  The CA acts as a mutually trusted third party, a root of
   trust.

   Certificate-based identities are limited in scope by the issuing CA,
   or by the namespace of the application responsible for issuing or
   validating the identity.

   Attempting to use organizational PKI outside the organization can be
   challenging.  In order to authenticate a certificate, the
   certificate’s CA must be trusted.  CAs have no way of controlling
   identifiers in certificates issued by other CAs.  Consequently,
   trusting multiple CAs at the same time can enable entity identifier
   collisions.  Asking an entity to trust your CA implies trust in
   anything that your CA signs.  This is why many organizations operate
   a private CA, and require users and devices connecting to the
   organization’s networks or applications to possess certificates
   issued by the organization’s CA.

This whole section up to here feels like kind of a cartoon sketch of
the PKI (BTW, a term which is introduced without context). Specifically:

- It kind of ignores that a PKI often has a trust hierarchy, so
  I might not need to trust the CA that issued the EE certificate.

- It conflates two different notions (1) issuing identities and
  (2) attesting to identities. When the subject of a certificate
  is a domain name, as in the WebPKI, then there is not actually
  a risk of "identifier collisions", because every domain name
  is issued to one entity. There is a risk of misissuance, but
  that has nothing to do with there being multiple CAs.

- It's not necessarily true that asking an entity to trust your
  CA implies trust in anything that your CA signs. The RP could
  have some sort of external policy.

- I don't think that this trust issue is the main reason that
  organizations operate a private CA; I'm certain it's not the
  only one as this text suggests.


   These limitations make the implementation and ongoing maintenance of
   a PKI costly, and have a chilling effect on the broader adoption of
   certificate-based IoT device identity and user identity.  If
   certificate-based device and user identity were easier to manage,
   more broadly trusted, and less operationally expensive, more
   organizations and applications would be able to use it.

   The lack of trust between PKI domains has lead to a lack of simple
   and globally scalable solutions for secure end-to-end inter-domain
   communication between entities, such as SIP phones, email and chat
   accounts and IoT devices belonging to different organizations.

I don't understand what this text has to do with the text above it at
all, which is about *organizational* CAs, but the examples you give
actually require universally verifiable identities.

Moreover, these specific examples really seem handwavy and out of
touch with operational realities. It's really not the case that the
reason we don't have secure end-to-end interdomain communication in
these areas is because it's hard to get certificates for user-level
end entities. To take one example, I know quite well, the reasons we
don't have secure end-to-end interdomain instant messaging are (1)
that providers don't want it and (2) that the naming structure for
names in messaging doesn't map well onto a universal system. There has
been a lot written about this in the context of MIMI, for instance
[0]. Moreover, while there is really active work in the area of identity
for instant messaging, it doesn't look anything like using DNSSEC.
I could make similar comments about SIP and email.

It may well be the case that there is some problem to be solved here,
but this text is not in any way persuasive of that.


Sections 2/3.
I don't find these particularly helpful, but I'm also going to skip
commenting on them.


S 4.1.
I think this really needs to explain why what you're proposing here is
superior to the WebPKI, which is already designed to authenticate the
server in the way you are commonly proposing, and which we know is
commonly used this way for machine clients. I'm hard pressed to think
of any context in which you would want to authenticate users this way,
because (1) user identities are typically service specific and (2)
people just don't really want to use mTLS for user authentication.

As noted in a separate email, I think this whole architecture is
wrong: instead of triggering a DNS lookup, you should provide the
whole DNSSEC chain in the Certificate message. This is more efficient,
provides greater privacy, and obviates the DoS issues you raise here.


S 4.1.1.
What you describe here seems like it's basically mTLS, except with
DANE replacing the ordinary PKI. I can imagine people might want this,
but I would observe that your text about how this works with load
balancers is kind of besides the point: mTLS doesn't work well with
load balancers because usually the endpoint behind the load balancer
needs the client's identity, and it's not available at the HTTP layer,
so you end up having to reinject it in some new header. That's
inconvenient and one reason people don't like mTLS!

S 4.1.2
I'm quite skeptical that anyone is going to want to do what is
proposed here. You're going to ask Web applications to do some DNS
resolution followed by a DNSSEC validation? Ignore security questions
(often you want to sandbox your application so it can't make any
outgoing requests!), this requires pulling in some external library,
etc. etc.


S 4.1.3-4.1.7.
I don't know much about these cases, so I'm not going to comment.


S 4.1.8.
This text seems to me to reflect a fairly serious misunderstanding of
the situation with both WebRTC and SIP.

First, WebRTC doesn't give users identities even within a given
domain. Instead, endpoints are just defined by hashes of (typically
self-signed) certificates, which are carried in JSEP. Moreover, it
doesn't have an interdomain mode at all; interoperability between
services is out of scope for WebRTC. However, if someone were to
invent some kind of WebRTC federation (e.g., bridging to SIP), it
would work just fine with WebRTC as-is, because the fingerprints would
just get carried along. Importantly, all that would be required here
is authenticating the servers, not the users. It might eventually
be attractive to authenticate users, but that's really far down the
road in terms of the challenges here.

As far as SIP goes, there are actually two classes of identifiers with
SIP, e-mail style addresses and E.164 numbers. However, now that pure
Internet VoIP communications has been taken over by WebRTC and
proprietary apps, most uses of SIP are actually in contexts where the
identifiers are E.164 numbers, and we already have a PKI-based
solution for that, namely STIR/SHAKEN. There's no good reason to think
this would be somehow improved by mapping it onto the DNS and a number
of good reasons to think it would not be, starting with the failure of
ENUM. I note that you cite johansson-sipcore-dane-sip, but I hardly
think a now 11+ year old expired draft is doing much in terms of
supporting the viability of this approach.

-Ekr

[0]
https://datatracker.ietf.org/doc/draft-interop-mimi-discovery-requirements/
https://educatedguesswork.org/posts/messaging-e2e/