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

[tirumal reddy <[e-mail]>]

Hi Ekr,

Please see inline

On Thu, 28 Dec 2023 at 02:46, Eric Rescorla <[e-mail]> wrote:

> 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.
>

The issuance of a large number of certificates is one of the problems,
other challenges include the dependency on the CA to issue large number
certificates in a timely manner and to promptly replace expired
certificates. We considered other possible solutions, please see
https://datatracker.ietf.org/doc/html/draft-reddy-add-delegated-credentials-03#section-6
for details. Such a scale has not been discussed in any other use cases
like CDNs using STAR certificates.


>
> - 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.
>

The attacker cannot impersonate CPE unit 2 without knowing the credentials
used by the endpoints for authenticating to the CPE unit 2.


>  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.
>

The necessity of running encrypted DNS forwarders on the CPE is discussed
in Section 1.2 of the draft. The DNS client is unaware of the security
protocols employed to encrypt data from the endpoint to the CPE, and it is
also uncertain whether the DNS server and CPE are co-located or not.


>
> 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).
>

The managed CPEs are hardened devices capable of running network security
services. Security vendors have been offering security services on CPEs for
several years, deploying them on millions of devices to secure Home
networks, SOHO and SMB. For example, you can refer to
https://www.mcafee.com/support/?locale=en-US&articleId=TS102712&page=shell&shell=article-view
for
details and such solutions are deployed by ISPs.

Cheers,
-Tiru


>
> 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
>>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>