Re: [Danish] Proposed WG Charter

[Viktor Dukhovni <[e-mail]>]

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.

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

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

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

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

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

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

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

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

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

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