Re: [Danish] Proposed WG Charter

[Ash Wilson <[e-mail]>]

Hi Viktor,
Thanks for the detailed feedback! Responses in-line below...

On Sun, Jun 13, 2021 at 1:52 PM Viktor Dukhovni <[e-mail]>
wrote:

> On Sat, Jun 12, 2021 at 08:25:07AM -0700, Ash Wilson wrote:
>
> > This is the final text for the proposed charter. We are seeking
> > support for the formation of the working group, as well as support for
> > implementation, adoption, and documentation efforts.
>
> I see that others have commented positively on the charter, and yet
> somehow for me it seems rather muddled.  It is not clear to me what
> the motivating use-cases really are, nor how DANISH would resolve
> the key difficulties in those use-cases.
>
> There is no explanation of whether the perceived barriers to DNSSEC
> adoption are on the authoritative or resolver side, or who are the
> primary intended users (consumer, enterprise, other?) for PKI a la
> DANISH.
>
I think that a proper survey to understand what DNSSEC adoption is
struggling would be a worthwhile endeavor, and registrars are in a
great position to do that well. The objections I've encountered to DNSSEC
(in having conversations with would-be implementers) relate generally to a
perception that the benefits do not outweigh the risks. Some of those risks
are related to technology challenges, and some relate to hiring the right
skillset to maintain and troubleshoot a DNSSEC-protected domain. In
changing the location of DNSSEC in the adoption path for DNS-based
identities, we allow organizations to experience some success and build
confidence in the DNS-based identity strategy, which will further
incentivize the eventual adoption of DNSSEC.


> > The now closed DANE working group (WG) produced a mechanism that
> > supported authentication of TLS server identities via a DNSSEC-secured
> > infrastructure.  Operational experience with DANE has validated the
> > utility of a DNS-enabled mechanism for discovering authenticated keys,
> > but has also shown that reliance on DNSSEC is a significant barrier to
> > adoption.
>
> The term "discovering authentication keys" is not defined here.  It is
> not clear that avoiding DNSSEC will make things simpler.  Which is the
> more important barrier here, zone signing, or access to validating
> resolvers?
>

Would replacing 'discovering authenticated keys' with 'discovering keys or
hashes to support TLS server authentication' remedy the lack of clarity?

A DNS-based public key discovery mechanism for authenticating message
signatures, which does not rely on DNSSEC, may be experimented with and
adopted by any domain. If DNSSEC is a requirement for the message security
use case (public key discovery for signature validation), then only 2.47%
of all .com domains may even experiment with it. Justifying a transition to
DNSSEC for an organization can be an uphill battle. If DNSSEC is a
requirement for further exploration of a strategy that's already shown
success, the chance of eventual adoption of DNSSEC will be greater.


> > The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to
> > extend DANE to encompass TLS client and message sender identities.
>
> Extending DANE to client auth is certainly an option for "devices" that
> one might reasonably want to register in DNS.
>
> > DANISH will also define a mechanism for messaging use cases that
> > allows DANE DNS record types to be secured by the Web PKI as a
> > transition strategy for domain owners who have not yet implemented a
> > DNSSEC-based trust model.
>
> The phrase "DANE DNS record types" is not defined.  Nor is it clear what
> it might for DNS records to be "secured by the Web PKI".
>

Detail was intentionally left out of this part. We had some discussion at
the last BoF, and a draft process
https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd/ also exists in
the form of running code. However, there may be a more elegant way to
approach this, and we didn't want to go into exhaustive detail on the
transitional mode when the final state (TLS protocol support for DANE
client identity) still needs more discussion and detail added to the
specification. This informed the timing components of the deliverables
section of this charter, where we expect to complete the specification for
the desired end-state, and then ensure the transitional mode is
appropriately aligned.


> Here you speak of "domain owners", placing the focus on the signer side.
> Signing domains, and keeping them signed, is at this point sufficiently
> easy, that there's no longer any justifiable reason to design
> work-arounds for barriers to zone signing.  If that's the obstacle, I am
> not at all sympathetic to ugly work-arounds that simply postpone doing
> it right.
>
> > A Certificate Authority (CA) is one example of a PKI which can be used
> for
>
> FWIW, the established term of art is "Certification Authority".
>
> > establishing trust in public keys. CAs only guarantee the uniqueness of
> an
> > identity’s name within the context of the CA, and multiple CAs may sign
> > certificates for different entities bearing the same name. DNSSEC is
> > another PKI, which is bound to the DNS namespace.
>
> The use of "uniqueness" here is rather unclear.  There's nothing wrong
> with multiple certificates each binding a key to some shared name, it
> just means that all the keys are associated with the same subject.  Nor
> is it necessarily a problem if such bindings are obtained from multiple
> CAs (provided they are all properly validated and authorised).
>

The challenge is in ensuring that an entity is bound to the correct role in
an application. If there is ambiguity in assigning information to its
source, or determining the appropriateness of a source for providing the
information to the application, then the information is not trustworthy. In
a broader context, machines are being trusted not only to collect
information and perform actions, but increasingly to decide when certain
actions are to be performed. A more concrete example might be a system
which manages the addition of chemicals (fluoride, etc) to a city's water
supply, in response to telemetry from sensors. If a sensor can be
impersonated via naming collision (intentionally or otherwise), a decision
made by a machine to react to sensor telemetry could have a profoundly
negative effect on the human population of the city.


> > The DNS namespace, together with DNSSEC, forms the most widely-recognized
> > namespace and authenticated discovery mechanism on the Internet.
>
> Not clear what this is intended to convey.
>
> An agreement on one namespace is essential for preventing naming
collisions.


> > DANE builds on this authenticated discovery mechanism to enable public
> > key-based TLS authentication which is resilient to impersonation, but
> > only for TLS server identities.
>
> More precisely, how one locates the relevant RFC6698/7671 TLSA records
> for use with TLS is presently only defined for the server side of a TLS
> connection.
>
> > The use of CA-based PKI alone for client and message sender
> authentication
> > creates the possibility of naming collisions when multiple CAs are
> trusted
> > within the same application.
>
> It is rather unclear what this is getting at.  Perhaps it i trying to
> evoke lack of effective name constraints in the WebPKI?


Yes, you are correct.

>
>
> 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.
>
> Again, what exactly is this tryign to get at?
>

Time is spent onboarding devices to the same PKI, to avoid naming
collisions.

>
> > Expanding the use cases for DANE to support the representation of TLS
> > client and message sender identities will enable unambiguous
> authentication
> > across CAs, for client/server TLS sessions as well as message-oriented
> > information flows.
>
> It seems that solving "ambiguity" is a major concern.  So the term needs
> a clear definition and some motivating examples.
>

Ambiguity here refers to naming collisions possible when using multiple PKI
within the same application.
What do you think about using "naming collision-free authentication across
CAs" instead?

>
> > The greatest barrier to DANE adoption has been the DNSSEC requirement.
>
> But which barriers if any are applicable to the DANISH use-case?  DNSSEC
> zone signing?  DNSSEC resolution on roaming devices?  Or tools to
> automate publishing data in DNS (signed or not), monitoring, ...
>
> DNSSEC zone signing


> > DANISH will provide a method of certificate and trust chain discovery for
> > private PKIs,
>
> What is "trust chain discovery"?  How is different from including all
> the relevant certificates with the message?  What is "certificate
> discovery"?  What makes these relevant to IoT?


IoT applications frequently have network constraints which make the
in-message transmission of certificates and chains impractical or
impossible.

For example: A device uses a cellular connection to transmit water level
measurements to a central service, for a city's storm water management
application. Since falsified measurements could lead to chaos, we want
signatures on all of those measurements so that we have some measure of
sender authentication/attribution. The cellular bill would be substantially
higher if the cert/chain were transmitted along with every measurement and
signature. Compare that to just transmitting the measurement, the device's
DNS name, and a signature. The authenticating central application can then
use a less constrained network connection to perform out-of-band
certificate discovery, based on the sending device's name, found in the
message itself.

>
>
> to enable the messaging security use case, in a manner which will work
> > securely in the absence of DNSSEC.
>
> Why is avoiding DNSSEC simpler than making it more compelling to deploy?
>

Allowing some limited success with DNS-based identity is expected to
further incentivize adoption of DNSSEC. This isn't about avoiding DNSSEC.
Rather, it's about postponing the requirement so that an organization can
demonstrate value in an identity strategy that eventually requires DNSSEC.

>
> > -Scope of work
> > DANISH will specify the TLS session and message security use cases and an
> > architecture describing the primary components and interaction patterns.
>
> I think the charter should go some way to clarifying the intended use
> cases.
>
> --
>     Viktor.
>
> --
> 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.