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

[tirumal reddy <[e-mail]>]

On Tue, 16 Jan 2024 at 20:02, Eric Rescorla <[e-mail]> wrote:

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

Please refer to
https://www.ietf.org/archive/id/draft-reddy-add-delegated-credentials-03.html#section-6
for details on the limitations of alternate solutions. We could not
identify any better options for hosting an encrypted DNS server on a large
number of managed CPEs. It would be helpful to explore any other
alternative solutions and discuss their pros/cons.


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

The PKI certificate is issued to a service in the infrastructure owned by
the entity managing the CPEs. The private key associated with the
PKI certificate is used to sign the delegated credentials on each CPE. I
don't get how compromising CPE unit 1 would leak 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.
>>
>
> Yes, I'm aware this configuration is widely deployed. That doesn't make it
> a good idea.
>

Why is it not a good idea to run encrypted DNS forwarder on a hardened CPE ?

-Tiru


>
>

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