DANE Authentication for Network Clients Everywhere
charter-ietf-dance-01

Changed charter milestone "TLS extension to indicate DANE identification capability and the client's DANE identity name to WGLC", set description to "TLS extension to indicate DANE identification capability and the client's DANE identity name to WGLC (PS)"

[Ballot comment]
The charter defines “RPK” as “raw public keys”. This is a near-collision with “RPKI” defined in RFC 6480 as “resource public key infrastructure“. Maybe this use of “RPK” is long-standing practice, in which case of course there’s not much to be done. I point it out in case the observation is useful. (Also, the acronym although defined is never referenced in the charter, so the definition could easily be left out if desired. The same is true of a few other acronyms.)

Changed charter milestone "TLS extension to indicate DANE identification capability and the client's DANE identity name to WGLC", set due date to January 2023 from May 2022

[Ballot comment]
    The DNS namespace, together with DNSSEC, forms the most
    widely-recognized namespace and authenticated lookup mechanism on the
    Internet. DANE builds on this authenticated lookup mechanism to enable
    public key-based TLS authentication which is resilient to impersonation,
    but only for TLS server identities.

We might reference RFC 6698 for DANE.

OVERLY PEDANTIC NITS

    The process of establishing trust in public-key-authenticated
    identity typically involves the use of a Public Key Infrastructure
    (PKI), and a shared PKI root of trust between the parties exchanging
    public keys.

"shared PKI root of trust" seems to imply that both parties have
credentials that chain up to the same root of trust (or at least that
the level of trust in the root is shared between parties), which need
not be the case.  In principle the parties can use credentials anchored
at different roots of trust, so long as the verifier is willing to use
the corresponding root of trust for this purpose.  So we might say
instead "and a root of trust deemed valid by the entity validating the
authenticated identity".  Or we could ignore it, and try to not be
overly pedantic.

[Ballot comment]
Sounds useful.

I'm wondering whether restricting the initial use case to TLS client only will limit its usefulness in IOT onboarding?

I'm not sure if it is important, but from the scope of work, it is unclear to me whether the format of DNS DANE records would need to change, or whether this is use a new use of the existing DANE records.


Nits:

Para 3:
"DANE builds on" => "DANE built on"?  Or otherwise perhaps change "DANE did not" to "the DANE WG did not".

Para 4:
"large deployment" => "large deployments"?

Are the milestone dates correct (i.e., the architecture and use cases is expected to be standardized after the solution)?

[Ballot comment]
To the IESG -- As you review this charter text and the associate background, note that DANCE is motivated by the two DANISH BoFs held during IETF 110 and 111.  One of the items of feedback was to generalize the proposal to remove the IoT focus, hence the renaming of the group (from DANISH to DANCE).  Background materials from the BOF are at:

* DANISH BoFs:

* DANISH mailing list archive: