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

[Eric Rescorla <[e-mail]>]

On Tue, Jan 16, 2024 at 4:27 AM tirumal reddy <[e-mail]> wrote:

> 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.
>
> Yes, I read those sections of the draft, but as I said I didn't find those
arguments persuasive and these issues seem like they ought to be solvable.



>
>> - As far as I can tell, the current design allows an attacker wh
>>   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.
>

In this situation, the attacker has already compromised the relevant
network.

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

Yes, I'm aware this configuration is widely deployed. That doesn't make it
a good idea.

-Ekr


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