Re: [Add] The ADD WG has placed draft-reddy-add-delegated-credentials in state "Call For Adoption By WG Issued"

[Eric Rescorla <[e-mail]>]

Document: draft-reddy-add-delegated-credentials-03.txt

I agree with Martin Thomson and others that we shouldn't adopt this
document at this time. I have several concerns about this specific
technical proposal.

- I don't find the arguments about why this can't use ordinary WebPKI
  certificates persuasive; it certainly seems that there are
  challenges with issuing a lot of CPE certificates, but those seem
  like they ought to be solvable.

- As far as I can tell, the current design allows an attacker who
  compromises CPE unit 1 to impersonate CPE unit 2, because they have
  DCs rooted in the same certificate. Given that there are likely to
  be a very large number of each unit, key extraction seems
  inevitable. That seems like an undesirable set of security
  properties even if the client gets its opinion about which reference
  identity to expect from the CPE. It's a more serious problem if
  either (1) the client gets its opinion in some other way or (2) the
  client behaves differently if DNS is encrypted.

Moreover, as Paul Wouters notes, it's not clear what the security
benefit of this proposal is. If the local network is secure, then
traffic to the CPE will be encrypted anyway, so it's not clear
what transport encryption of DNS is doing for us. On the other
hand, if the local network is insecure, then the attacker may
be able to impersonate the CPE and we are back to the extraction
case above.

More generally, the point of this design seems to be to preserve
the ability to have the CPE as an active participant in DNS
resolution, rather than just transiting the traffic. While
I appreciate that the CPE is commonly used as a control point
as described in S 1.1, this actually seems like not a great
practice given the notorious insecurity of home routers; rather,
it would be better to have name resolution encrypted directly
to the ISP resolver itself (and even better if there were some
way for the client to determine what that resolver's reference
identity was, but one step at a time).

Finally, Michael Richardson writes:

> I want to remind people, particularly those who have spoken against the
> document that **Adoption does not mean publication**.

This may in fact be formally true, but as a practical matter
documents acquire inertia once they have been adopted. So,
while it's reasonable to adopt a document in an imperfect
state under the assumption that those imperfections will
be corrected prior to publication, if the objection is that
the document is conceptually flawed, then the right answer
is not to adopt it at all.

-Ekr




On Mon, Dec 11, 2023 at 2:09 PM Martin Thomson <[e-mail]> wrote:

> I don't see this as ready for adoption.  I have a lot of questions that
> the document doesn't answer.
>
> Why is this on the standards track?  It's just say "you could do X", where
> X is a standards-track document.  Informational is sufficient.
>
> Given the relative levels of DC adoption, I'm not sure that this is going
> to make this deployment model much more accessible, but if OS vendors are
> on board, perhaps we'll see this change.
>
> The deployment model for this is pretty narrow, given that DC is
> essentially a license to impersonate.  The idea of "managed" devices makes
> it plausible at least, but the use of specifically-delegated names is
> essential.  That means that the central DNS is obligated to support ACME so
> that it can obtain a bunch of certificates.  (That doesn't mean STAR.
> Regular ACME would suffice; see below.)
>
> The tlsdelegation SvcParam makes no sense to me.  If the client has
> configuration sufficient to authenticate, that can include whatever
> information it needs to find the right endpoint to ask for a delegation.
>
> There is no delegation protocol defined.  Is it the case that this is
> intended to be proprietary in the same way that authentication is?
>
> I don't agree with the premise that ACME doesn't work for the CPE.  That
> would be a simpler overall system.  It doesn't need to be STAR.  The CPE
> has some means of obtaining a name from its management system.  Then it
> uses ACME.  Maybe it uses the management system to support the challenge
> (for the emplacement of DNS records, say).  Maybe this part of the protocol
> is standardized, maybe not.
>
> Cheers,
> Martin
>
> On Sat, Dec 9, 2023, at 14:09, IETF Secretariat wrote:
> > The ADD WG has placed draft-reddy-add-delegated-credentials in state
> > Call For Adoption By WG Issued (entered by Glenn Deen)
> >
> > The document is available at
> > https://datatracker.ietf.org/doc/draft-reddy-add-delegated-credentials/
> >
> > Comment:
> > WG Adoption call will run until December 15 2023
> >
> > --
> > Add mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/add
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>