Subject: Re: [CDNi] URI Signing Shared Key Question

From: Phil Sorber <[email-masked]>
Date: Tue, 22 Mar 2022 10:57:09 -0600

This is the PR that I'd like to apply to change from SHOULD NOT to MUST NOT.

https://github.com/PSUdaemon/URISigningSpec/pull/84

On Thu, Jan 13, 2022 at 8:26 PM Kevin Ma <[email-masked]> wrote:

> Hi Phil,
>
>   The shared key redistribution problem only applies to DNS redirection?
> So we'd essentially be saying DNS redirect needs to use asymmetric keys for
> CDNI, but for non-CDNI cases (i.e., only one level of delegation) symmetric
> keys are fine?
>
>   (As an individual) That seems reasonable to me.
>
>   I also do not know if that affects any production use cases and would be
> interested in hearing from other WG members who have production insights.
>
> thanx!
>
> --  Kevin J. Ma
>
> On Tue, Jan 4, 2022 at 7:43 PM Phil Sorber <[email-masked]> wrote:
>
>> I got more pushback on this again, but I also got another suggestion. Not
>> sure if I missed this before or not, but I was told by Ben Kaduk that he
>> would be OK if we kept the shared key option for the "single-hop" case but
>> removed the distributed case and thus removed the shared key distribution.
>> Meaning if I just wanted to have someone internal to my company get access
>> to the content I could create a shared key version that would validate.
>> However, you would not be able to have a dCDN validate with a shared key.
>>
>> AFAIK, no proprietary implementation really touts that as a feature, but
>> I may be way off base, so I wanted to get more feedback. Does this seem
>> like a reasonable compromise?
>>
>> Thanks.
>>
>> On Wed, Nov 10, 2021 at 10:54 AM Kevin Ma <[email-masked]>
>> wrote:
>>
>>> Hi All,
>>>
>>>   (As an individual) When we first started the draft, all the vendors
>>> were using shared keys, so it was natural to have that as a feature to ease
>>> migration and improve adoption.  It looks like shared keys are still used
>>> in other URI signing schemes today, so I can only assume it is still a
>>> desirable feature, even if it is not secure (along with the other known
>>> caveats about the security of URI signing in general).  I could go either
>>> way on this one.  We're not preventing anyone from using shared keys, but
>>> we may reduce adoption if it is not readily apparent how to use them.  It's
>>> a similar argument to the client IP question: are users better off with URI
>>> signing with a shared key than some other proprietary protocol (not vetted
>>> by secdir) that more readily fits their use case?  I would lean toward
>>> stronger language about it being not recommended.
>>>
>>> thanx!
>>>
>>> --  Kevin J. Ma
>>>
>>> On Tue, Nov 9, 2021 at 5:39 PM Phil Sorber <[email-masked]> wrote:
>>>
>>>> This is one of three questions that I had after last call feedback. I'd
>>>> like to hear any opinions on the matter from the working group. I will be
>>>> pointing to this thread for explanation/justification about the changes or
>>>> lack thereof to the document. Thanks.
>>>>
>>>> Do we want to remove text about Shared Key support in favor of a
>>>> smaller comment about how it's possible to do for an internal use case, but
>>>> not condoned or recommended by the document, or do we want to keep it as is
>>>> and cite having niche value and make sure we have strong language about the
>>>> dangers of using it?
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>
>>>