Re: [Danish] Proposed WG Charter

[Michael Richardson <[e-mail]>]

I will put the first iteration into:
  https://github.com/mcr/danish-bof

and then my proposed changes, and then editorial around that.
I don't feel that I/we have consensus around my rewrite yet, but I'll post
about that, and maybe we can agree.

Roman Danyliw <[e-mail]> wrote:
    >> -Problem statement

    > Editorially, it would be helpful to have symmetry between the objective
    > and the problem statement; and clear delineation between the two
    > identified problems (this might also be the tee of for naming the two
    > use cases).

I'm not sure I understand what you mean here.
Are you saying that the text:

}    The WG will also use DANE to establish identities for store and forward of
}    messages using sender identities.      [better wording sought]

needs to align better?

    >> 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. A Certification Authority (CA)
    >> is one example of a PKI which can be used for establishing trust in public keys.
    >>
    >> The DNS namespace, together with DNSSEC, forms the most widely-recognized
    >> namespace and authenticated discovery mechanism on the Internet.
    >> 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.
    >>
    >> 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 private CA specific to that vertical.
    >> This creates a silo effect where different parts of large deployment can not
    >> communicate.  For instance the heating cooling system of a building can not
    >> authenticate the lighting control system.
    >>
    >> Many IoT deployments use some kind of message bus (for instance MQTT) to
    >> exchange data, and there is a strong desire to add message-level security
    >> (MLS) to the objects which are exchanged.  While there is TLS for connection
    >> security, it does not extend to what is communicated and so does not convey
    >> authority to make a claim, while a MLS would provide that

    > -- I don't know if I follow all of the use cases so I wondering if it
    > should it be assumed that there is always TLS for communication
    > security (i.e., “while there might be TLS in use for connection
    > security ...”)

Yes, that's a reasonable qualification.  MQTT doesn't always require TLS.
(It's shocking to me)   ACE is doing a profile for it.

    > -- What is meant by “it doesn’t extend to what is communicated”?  Is it
    > that there aren’t end-to-end properties due the middleware/message bus?
    > Recommend spelling this out.

Nothing specific to MQTT: most buses have this property.

    > -- (Editorial) Recommend avoid the term “claim” as it might be
    > perceived as overlapping with “claims” from things like OAuth.

The attack is that node X says that the temperature is 37C, and X is not a
temperature sensor.   And here I was worried you'd complain that "claim"
conflicted with RATS :-)
What term should we use here?  They all seem conflcited to me.

    > -- (Editorial) Recommend avoiding using the term “MLS” (per above,
    > object security makes more sense), but also because of possible
    > confusion with the MLS WG.

If we are in agreement that it will all become "object security", then good.

    >> A DNS name is a useful unique identifier to which humans interact with well,
    >> and which can be used (thanks to DNSSEC and DANE) to attach a key by which
    >> to authenticate the message sender identity.

    > This is true, but doesn’t seem relevant to the problem statement.

Hmm!
This is surprising.  I thought that was 90% of the point of the work!

    >> DANISH will specify the TLS session and message security use cases and an
    >> architecture describing the primary components and interaction patterns.

    > Nit.  Is a “TLS session” use case the same as DANE-based TLS client
    > authentication?  Recommend consistent use case language.

okay.

    >> DANISH will establish usage conventions for DANE DNS records to represent
    >> client identity for TLS connections and how to perform public key discovery for
    >> message security use cases, like the establishment of message sender identity.

    > -- I’m tripping over the editorial construct here.  I think the
    > sentence should say that the client identity “usage conventions” apply
    > to both TLS client auth and object security.  The discovery mechanism
    > applies only to the object security use case.

agreed.

    > -- Is the scope more than usage conventions?  It seems like it might
    > include not only the specification of client side credentials but also
    > (?) the operational practices for using them?

I think that the answer is yes, but can you give me an example of an
operational practice that we'd be specifying?

    >> DANISH will coordinate with the TLS working group to define any required TLS
    >> v1.3 protocol updates required to support client authentication using DANE.
    >>
    >> {XXX cross this out?
    >> DANISH will standardize a protocol and specify operational recommendations
    >> for the use of Web PKI to authenticate the discovery of private PKI certificates
    >> and trust chains via DANE DNS record types, in the absence of DNSSEC, in
    >> support of the message security use case. }
    >>
    >> 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:SMIMEA (RFC 8162), Proxy headers (RFC 7239), IANA email
    >> authentication headers, and TCP proxy TLVs standardized by haproxy.

    > Agree with the helpful focused provided by removing of above paragraphs.

Thank you, that's very useful.

    >> -Deliverables:
    >> DANISH architecture document
    >> 9 months

    > Where are the use cases going to be documented?  Is this a “DANISH use
    > case and architecture” doc or do we need two deliverables here (use
    > case and architecture).  No feelings either what on whether one is
    > better than two.

I think you know how it went in RATS, and I think that it's a pattern we
should repeat.   I can reply to this comment afterwards to explain, as I bet
90% of people stopped reading :-)

    >> DANE for client certificates (current draft)
    >> 6 months

    > “DANE for client certificates” as a designator doesn’t follow for me
    > from the above text (although I realize that it comes from individual
    > draft text).   Is this the deliverable that also covers getting the
    > keys for the object use case?  Most of the text above generically talks
    > about client identity but here it's explicitly client certificates (I’d
    > suggest clarity and consistency)

The 1986s ITU-T police are gonna get you for even thinking that identity is
other than a certificate :-) :-) :-)
Expect them to show up in red Duran Duran jackets.

Yes, I think that it includes the object security use case.
I guess it should say, "DANE for device certificates" maybe?

    >> DANE for TLS client authentication (current draft)
    >> 6 months

    > Finally, since there are existing drafts
    > https://datatracker.ietf.org/doc/draft-huque-tls-dane-clientid/ and
    > https://datatracker.ietf.org/doc/draft-huque-dane-client-cert/, is
    > there sufficient interest in calling them out as starting points of the
    > work?

I guess that's a consensus question, right?

{off to run}

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide