Subject: Re: [Danish] Proposed DANISH charter

From: Roman Danyliw <[email-masked]>
Date: Thu, 3 Jun 2021 22:33:51 +0000

Hi!

Thanks for all of the work to date in refining the charter.  Proposed clarifications and questions noted below.

> -----Original Message-----
> On Fri, 21 May 2021 05:24, Ash Wilson <[email-masked]> wrote:
> 
> Hi everyone,
> I've updated the text stating DANE's original purpose, according to
> recommendations from Paul and Jacques.
> 
> Any other comments or suggestions for clarification? We've had some dialogue
> and I want to make sure that anything that's not sufficiently clear for a charter-
> level doc is appropriately addressed.
> 
> -----
> Objective
> DANE's original purpose only covered authentication for the TLS server identity.
> The DANISH working group seeks to extend the DANE standard to encompass
> client identity and message sender identity use cases. DANISH also seeks to
> define a transitional mode for DANE, which will allow the safe adoption of
> DANE for domain owners who have not yet implemented DNSSEC..

It would be useful to clarify the applicable use cases of DANISH. The subsequent text, describes a "messaging security" and "object security" use case.  The text above describes a "client identity and message sender identity use cases".  How many use cases are really in play?  It would be unrealistic to define them in detail here, but as they are framing the scope of work, they should at least superficial be introduced.

If I understand the objective correctly, would this be a fair restatement (note that this doesn't address the confusion noted above around the use case names):

Objective
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 DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to extend DANE to encompass client or message sender identities. 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.

> Problem statement

This problem statement text below doesn't seem to motivate the four use cases noted above.   For example object security noted in the work scope doesn't come up at all here.

> Using DANE for representing client identities safely allows authentication
> across CAs and prevents impersonation, because DNSSEC is used instead of a
> CA certificate and its associated trust hierarchy to bind an identity's name to a
> public key. Everyone agrees on the DNS namespace and the DNS root zone's
> DNSSEC trust anchor, eliminating the barrier to adoption for multiple private
> PKIs participating in application deployment.

These are very dense sentences.  It made is challenging for me to parse the problem -- rather it seems to instead state a solution: using DANE for client identities because DNSEC, secured through the trusted DNS root trust anchors.  It would seem to me that this text should cover the need for client identities (the DANISH name even applies application for IOT) as motivated by the second sentence of the objective section (" ... extend the DANE standard to encompass client identity and message sender identity use cases") and then transition to the ubiquity and common trust anchor that could be relied upon via DANE/DNSSEC

Nit, I wouldn't use the phrase "_[e]veryone_ agrees"

> The greatest barrier to DANE adoption has been the DNSSEC requirement.
> DANISH will seek to provide a method of certificate and trust chain discovery
> for private PKIs, to enable the messaging security use case. This alternative
> mode will allow the use of  Web PKI to securely discover certificates, in the
> absence of DNSSEC. 

The messaging use case envisioned here needs more description.  Some of the text also feel duplicative of what's said in the objective and scope of work.

> This allows for a gradual DANE adoption where DNSSEC is
> not in the initial set of requirements. If the application owner wishes to use
> DANE for mutual TLS authentication, the application owner must then
> configure DNSSEC for the zone.

> Scope of work

My proposed edits/comments below are intended to make the discrete lines of work clear and distinct.

> The DANISH group will produce an architecture document describing the
> primary application components, and their interaction patterns. 

This is clear.  For symmetry with the text below, I might restate it to be:

* Specify the <insert names if known; or perhaps none at all> use cases and an architecture describing the primary application components and their interaction patterns

> DANISH will
> establish usage conventions for DANE DNS records to represent client identity
> for TLS connections and how to perform public key discovery for object security
> use cases. 

Is this the same as saying:

* Specify operational practices and usage conventions for representing client identities for TLS connections in DANE DNS records

* Standardize a protocol (?) and operational practices for public key discovery in support of the object security use case

> DANISH will also define any required TLS protocol updates to support
> client authentication using DANE. 

Is this the same as saying:

* Standardize protocol extensions or updates to TLS v1.3 needed to support client authentication using DANE

> DANISH will define a method whereby Web
> PKI may be used in lieu of DNSSEC, using DANE DNS record types under specific
> use cases, as a transitional mode from Web PKI to the DNSSEC-based trust
> model.

This text doesn't seems to align with the style of the rest.  Is this the same as saying:

** Standardize a protocol (?) and specify operational practices to use the Web PKI to discover certificates and trust chains via DANE DNS record types in the absence of DNSSEC in support of the message security use case

Got to this point in the scope of work description.  Of the four named use cases, only object security was called out in this scope.  Is there are reason for that?

> While modifications to the following standards are not within the scope of the
> DANISH charter, the DANISH working group will take care to ensure a potential
> path for interoperability with the following standards, enabling potential future
> work: JOSE, COSE, Oauth2, MLS, EAP-TLS, SMIMEA (RFC 8162), SIP (RFC 5922),
> Proxy headers (RFC 7239), IANA email authentication headers, and TCP proxy
> TLVs standardized by haproxy.

I applaud the citation of related work and ensure things are appropriately coordinated.  However, this list seems rather long.  A successful DANISH WG of the future can re-charter when needed.  Please list only activities/work that needs active coordination or the work that provides design constraints to the proposed solutions per the specified milestones in this charter.

As one of the activities above noted a "define any required TLS protocol updates", listing coordination with the TLS working seems helpful.

Irrespective of the prose, for a complete charter, milestones with notional delivery dates are needed.

Regards,
Roman