Re: [Danish] Proposed WG Charter

[Ash Wilson <[e-mail]>]

Failed to reply to all earlier- here's the message back in-channel.

On Mon, Jun 14, 2021 at 10:53 AM Ash Wilson <[e-mail]> wrote:

> Hi Mike,
> Thanks for the feedback, responses in-line below...
>
> On Sat, Jun 12, 2021 at 9:56 AM Michael Richardson <[e-mail]>
> wrote:
>
>>
>> Thanks Ash for doing such a good job on this charter.
>> {I appologize for being rather lame in responding to the charter
>> discussions
>> in the past few weeks... some kind of COVID induced mid-life depression
>> around turning 50, and being unable to stay up all night writing code}
>>
>> The charter feels a bit long/detailed I think, with content that maybe
>> belongs in a problem statement draft.... But, if the IESG doesn't mind
>> that,
>> I don't.
>>
>> Some thoughts as I read it again:
>>
>> > but has also
>> > shown that reliance on DNSSEC is a significant barrier to adoption.
>>
>> also:
>> > The greatest barrier to DANE adoption has been the DNSSEC requirement.
>>
>> Reading this, I wonder if we really understand why DNSSEC has been so
>> hard to
>> get deployed among Enterprise entities.  TLDs have done it, because ICANN
>> forced them to.
>> As evidence, we don't need DLV anymore (I was involved in running it, and
>> decommissioning it).  What I'm trying to say/ask: if there in fact some
>> work
>> in understanding this?   An increasing number of DNS Registrars support DS
>> records, and CDS is supposed to make this even easier.
>>
>> Adding DNSSEC to a DNS server seems (to me), *significantly* easier than
>> operating a private CA, but its also apples vs oranges.
>
>
> In conversation with folks outside this group, but related to the topic at
> hand, the general perception is that the benefits of DNSSEC implementation
> do not outweigh the risk-related drawbacks. A few specific drawbacks cited
> have been: an anticipated increase in time to resolve DNS-related issues
> (uptime impact), a need for specialized knowledge in order to troubleshoot
> DNSSEC-related issues (hiring, training, retention), interoperability
> concerns with DNS-based load balancing and CDNs, and a general desire to
> avoid adding complexity that doesn't tie to some sort of competitive
> advantage for the business. This is anecdotal, and only represents the
> conversations I've had in trying to understand the feasibility of creating
> the protocol. A proper survey, perhaps conducted by registrars, would be
> quite useful for understanding and addressing the challenges that are
> impeding DNSSEC adoption.
>
>
>>
>>
>> > This allows for a gradual DANE
>> > adoption where DNSSEC is not in the initial set of requirements.
>>
>> It seems that if we make something that makes DNSSEC less important, that
>> DNSSEC will never become important.
>>
>
> DNSSEC is important. I think that the benefits just aren't overshadowing
> the perceived risks. If DNSSEC is a requirement to even try a DNS-based
> device identity strategy, R&D groups may just seek a path of less
> resistance. Even if an R&D group purchases a separate domain for testing
> with DNSSEC, they still have to sell the idea to the organization's
> technical leadership before it can be adopted under the organizational
> domain. Depending on the organization, that can be a big gamble. The R&D
> group has little room to negotiate the topic of DNS-based device identity
> with technical leadership, without a transitional mode.
>
> If we have a transitional protocol mode which allows gradual adoption,
> enterprises can more easily demonstrate initial success with DNS-based
> identities. The full set of benefits, like direct support in the TLS
> protocol, can only be realized by completing the transition to DNSSEC. It's
> much easier to justify the adoption of DNSSEC if it's tied to increasing
> the success of an existing initiative. We certainly don't want to diminish
> the importance of DNSSEC- this is about incentivizing implementation by
> making it a part of an adoption path for DNS-based identities.
>
>
>> > In response to the challenges related to ambiguity between identities
>> > issued by different CAs, application owners frequently choose to onboard
>> > IoT devices to a single CA. This process of credential issuance can be
>> > time-consuming, which is further exacerbated by the sheer number of
>> > entities participating in large-scale IoT deployments.
>>
>> So I understand why a single CA solves the potential identity confusion.
>> I don't understand why the scale matters here.  That sentence seems almost
>> a non-sequitor.
>>
>
> Each device needing to be onboarded to an organizational PKI takes a
> certain amount of time to establish an identity within that PKI. With a
> large-scale deployment with many thousands of devices, the provisioning
> process can be time consuming and impacts the cost of the project. If a
> supplier ships devices with immediately useful DNS-based identities, then
> the network and application onboarding time can be reduced, which has a
> favorable impact on project cost.
>
>
>> I think that the charter needs to introduce the message use case.
>> Or maybe delegate that more clearly.
>
> Good point. I was trying to keep it concise, but left out some detail
> where it could have been helpful.
>
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting
>> )
>>            Sandelman Software Works Inc, Ottawa and Worldwide
>> --
>> Danish mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/danish
>>
>

-- 

*Ash Wilson* | Technical Director
*e:* [e-mail]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.