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

• Ready for external review (00-00)
• Approve (00-02)

Note: This ballot was opened for revision 00-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

Erik Kline Yes

Roman Danyliw Yes

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: <https://datatracker.ietf.org/wg/danish/about/>

* DANISH mailing list archive: <https://mailarchive.ietf.org/arch/browse/dance/>

Alvaro Retana No Objection

Just a nit: s/any required TLS protocol updates required to support/any TLS protocol updates required to support

Francesca Palombini No Objection

John Scudder No Objection

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

Lars Eggert No Objection

Martin Duke No Objection

Murray Kucherawy No Objection

Robert Wilton No Objection

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

Zaheduzzaman Sarker No Objection

Éric Vyncke No Objection

In the first item in the scope of the WG there is no mention of DANE. Should there be one ?

(Benjamin Kaduk; former steering group member) Yes

    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.

(Martin Vigoureux; former steering group member) No Objection