Subject: [Danish] Proposed WG Charter

From: Ash Wilson <[email-masked]>
Date: Sat, 12 Jun 2021 08:25:07 -0700

Greetings,

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.

--
-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 TLS client and 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
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
Certificate Authority (CA) is one example of a PKI which can be used for
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 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.

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. 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. This process of
credential issuance can be time-consuming, which is further exacerbated by
the sheer number of entities participating in large-scale IoT deployments.

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.

The greatest barrier to DANE adoption has been the DNSSEC requirement.
DANISH will provide a method of certificate and trust chain discovery for
private PKIs, to enable the messaging security use case, in a manner which
will work securely in the absence of DNSSEC. This allows for a gradual DANE
adoption where DNSSEC is not in the initial set of requirements.

-Scope of work
DANISH will specify the TLS session and message security use cases and an
architecture describing the primary components and 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 message security use cases, like the establishment of message sender
identity.

DANISH will coordinate with the TLS working group to define any required
TLS v1.3 protocol updates required to support client authentication using
DANE.

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.

-Deliverables:
DANISH architecture document
9 months
DANE for client certificates (current draft)
6 months
DANE for TLS client authentication (current draft)
  6 months
DANE Transitional Mode Definition and Operational Guidance (non-DNSSEC)
1 year

-- 

*Ash Wilson* | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Jun 2021 12:56:04 -0400

Thanks Ash for doing such a good job on this charter.
{I appologize for being rather lame in responding to the charter discussions
in the past few weeks... some kind of COVID induced mid-life depression
around turning 50, and being unable to stay up all night writing code}

The charter feels a bit long/detailed I think, with content that maybe
belongs in a problem statement draft.... But, if the IESG doesn't mind that,
I don't.

Some thoughts as I read it again:

> but has also

> The greatest barrier to DANE adoption has been the DNSSEC requirement.

Reading this, I wonder if we really understand why DNSSEC has been so hard to
get deployed among Enterprise entities.  TLDs have done it, because ICANN
forced them to.
As evidence, we don't need DLV anymore (I was involved in running it, and
decommissioning it).  What I'm trying to say/ask: if there in fact some work
in understanding this?   An increasing number of DNS Registrars support DS
records, and CDS is supposed to make this even easier.

Adding DNSSEC to a DNS server seems (to me), *significantly* easier than
operating a private CA, but its also apples vs oranges.

> This allows for a gradual DANE

It seems that if we make something that makes DNSSEC less important, that
DNSSEC will never become important.

> 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. This process of credential issuance can be
> time-consuming, which is further exacerbated by the sheer number of
> entities participating in large-scale IoT deployments.

So I understand why a single CA solves the potential identity confusion.
I don't understand why the scale matters here.  That sentence seems almost
a non-sequitor.

I think that the charter needs to introduce the message use case.
Or maybe delegate that more clearly.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 13 Jun 2021 16:52:43 -0400

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?

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

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

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

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

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

> across CAs, for client/server TLS sessions as well as message-oriented

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

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

> architecture describing the primary components and interaction patterns.

I think the charter should go some way to clarifying the intended use
cases.

-- 
    Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 13 Jun 2021 18:21:42 -0400

> the key difficulties in those use-cases.

Same here. I did give feedback in the past already but especially the “client verification with and without dnssec” seem to be two widely different problems. And the one without dnssec (webpki) already exists ?

> one might reasonably want to register in DNS.

I have given this some thought in the last few weeks and I haven’t been able to find a use case where one actually wants client authentication using some IoT device on mobile data network. All use cases I can think of would not want to expose the client via public dnssec key registry or via public CA certs. I’d love to hear an example practical use case for DANISH.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Jun 2021 19:04:26 -0400

> more important barrier here, zone signing, or access to validating

I think that those are good questions, but it may be too much for a charter.
I don't think charters should worry about definitions :-)

We had a lot of nodding at the BOF.
Looking at the conflicts and having watched the conflicting WG sessions (and
who making noise there and not at our BOF) I'm sure that this at least party
due to some people being elsewhere :-)

    > FWIW, the established term of art is "Certification Authority".

:-)
What a great discussion that was a year ago, eh?

    > Why is avoiding DNSSEC simpler than making it more compelling to deploy?

I see this as a sticking point.
Those who like DNSSEC will dislike working around it.
Those who think DNSSEC will never sail will use this to sink it.

    > I think the charter should go some way to clarifying the intended use

I think that's actually more than a charter should say.
The charter needs to specific enough to tell people if they are interested in
the problem, and motivate them enough to read a use case document.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 13 Jun 2021 16:14:02 -0700

> Those who think DNSSEC will never sail will use this to sink it.

If the charter of this WG is to sink DNSSEC, that needs to be stated 
explicitly in the charter, and then say why this work should not be in 
other PKI-based WGs.

> I think that's actually more than a charter should say.

I could not disagree more strongly.

> the problem, and motivate them enough to read a use case document.

Charters are not documents to attract participants, they are 
descriptions of intended work. Given that this thread has brought out 
some significant disagreements on the use cases, the listing of use 
cases is all that much more imperative.

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Jun 2021 19:39:40 -0400

> explicitly in the charter, and then say why this work should not be in other
    > PKI-based WGs.

you said it better than I.

    > I could not disagree more strongly.

I suspect that we are in agreement.
It has to deal with the use cases, but I don't think it should go "some way".
There is a reason we write use case documents.

    > Charters are not documents to attract participants, they are descriptions of
    > intended work. Given that this thread has brought out some significant
    > disagreements on the use cases, the listing of use cases is all that much
    > more imperative.

Let me invert your point in order to also violently agree with it.
I didn't say that it was about attracting participants, but when people get
to it, it must be clear enough to tell them if they are in the right place.

So, a charter should have enough details so that someone can tell:
  a) if the WG is *not* working on some problem that they have.
     ("move along, nothing to see here".  That is, to "distract"
       participants. Although we don't useally consider "distract" to be
       opposite of attract)
     That's why we saying what's out of scope is so important.

  b) what problems the WG is working on.

Note that use cases are not the same as problems. Clearly related.

The RATS WG charter does not go into use cases at all.
We (I) wrote/collected a use case document (never to be published) very early in the
process so that the WG could focus better.   Parts of it, moved into the architecture.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Jun 2021 19:53:24 -0400

I think that the charter has too many words and too many goals.
I suggest leaving the DNSSEC-less stuff to a recharter.
Where was that github for this....

==== I suggest the following shorter charter

-Objective

The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to
extend DANE to encompass TLS client authentication using certificates.

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

-Problem statement

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.

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.

-Scope of work

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

-Deliverables:

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Jun 2021 11:30:24 -0400

> messages using sender identities.      [better wording sought]

I was asked offlist if we mean to speak about message security vs object
security.   I think that our community has some overlapping notions here.
The contrast was made between OSCORE (message) vs COSE (object).
I think, but I could be wrong, that the IETF MLS WG is actually creating
things with object security.  I think that this contributes to the confusion.

I think that the goal is probably best described as object security.
If others agree, then we should probably use that term in the charter.

---

From: Ash Wilson <[email-masked]>
Date: Mon, 14 Jun 2021 13:33:56 -0700

Hi Viktor,
Thanks for the detailed feedback! Responses in-line below...

> primary intended users (consumer, enterprise, other?) for PKI a la
I think that a proper survey to understand what DNSSEC adoption is
struggling would be a worthwhile endeavor, and registrars are in a
great position to do that well. The objections I've encountered to DNSSEC
(in having conversations with would-be implementers) relate generally to a
perception that the benefits do not outweigh the risks. Some of those risks
are related to technology challenges, and some relate to hiring the right
skillset to maintain and troubleshoot a DNSSEC-protected domain. In
changing the location of DNSSEC in the adoption path for DNS-based
identities, we allow organizations to experience some success and build
confidence in the DNS-based identity strategy, which will further
incentivize the eventual adoption of DNSSEC.

> more important barrier here, zone signing, or access to validating

Would replacing 'discovering authenticated keys' with 'discovering keys or
hashes to support TLS server authentication' remedy the lack of clarity?

A DNS-based public key discovery mechanism for authenticating message
signatures, which does not rely on DNSSEC, may be experimented with and
adopted by any domain. If DNSSEC is a requirement for the message security
use case (public key discovery for signature validation), then only 2.47%
of all .com domains may even experiment with it. Justifying a transition to
DNSSEC for an organization can be an uphill battle. If DNSSEC is a
requirement for further exploration of a strategy that's already shown
success, the chance of eventual adoption of DNSSEC will be greater.

> it might for DNS records to be "secured by the Web PKI".

Detail was intentionally left out of this part. We had some discussion at
the last BoF, and a draft process
https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd/ also exists in
the form of running code. However, there may be a more elegant way to
approach this, and we didn't want to go into exhaustive detail on the
transitional mode when the final state (TLS protocol support for DANE
client identity) still needs more discussion and detail added to the
specification. This informed the timing components of the deliverables
section of this charter, where we expect to complete the specification for
the desired end-state, and then ensure the transitional mode is
appropriately aligned.

> CAs (provided they are all properly validated and authorised).

The challenge is in ensuring that an entity is bound to the correct role in
an application. If there is ambiguity in assigning information to its
source, or determining the appropriateness of a source for providing the
information to the application, then the information is not trustworthy. In
a broader context, machines are being trusted not only to collect
information and perform actions, but increasingly to decide when certain
actions are to be performed. A more concrete example might be a system
which manages the addition of chemicals (fluoride, etc) to a city's water
supply, in response to telemetry from sensors. If a sensor can be
impersonated via naming collision (intentionally or otherwise), a decision
made by a machine to react to sensor telemetry could have a profoundly
negative effect on the human population of the city.

> An agreement on one namespace is essential for preventing naming
collisions.

> evoke lack of effective name constraints in the WebPKI?

Yes, you are correct.

> Again, what exactly is this tryign to get at?

Time is spent onboarding devices to the same PKI, to avoid naming
collisions.

> a clear definition and some motivating examples.

Ambiguity here refers to naming collisions possible when using multiple PKI
within the same application.
What do you think about using "naming collision-free authentication across
CAs" instead?

> DNSSEC zone signing

> discovery"?  What makes these relevant to IoT?

IoT applications frequently have network constraints which make the
in-message transmission of certificates and chains impractical or
impossible.

For example: A device uses a cellular connection to transmit water level
measurements to a central service, for a city's storm water management
application. Since falsified measurements could lead to chaos, we want
signatures on all of those measurements so that we have some measure of
sender authentication/attribution. The cellular bill would be substantially
higher if the cert/chain were transmitted along with every measurement and
signature. Compare that to just transmitting the measurement, the device's
DNS name, and a signature. The authenticating central application can then
use a less constrained network connection to perform out-of-band
certificate discovery, based on the sending device's name, found in the
message itself.

> Why is avoiding DNSSEC simpler than making it more compelling to deploy?

Allowing some limited success with DNS-based identity is expected to
further incentivize adoption of DNSSEC. This isn't about avoiding DNSSEC.
Rather, it's about postponing the requirement so that an organization can
demonstrate value in an identity strategy that eventually requires DNSSEC.

> Danish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/danish
>

--

---

From: Ash Wilson <[email-masked]>
Date: Mon, 14 Jun 2021 14:13:10 -0700

Sorry, meant to reply to the list.

On Mon, Jun 14, 2021 at 2:05 PM Ash Wilson <[email-masked]> wrote:

> Hi Paul,
>
> Very often, mobile data used for IoT ends up going into a message broker
> or message queueing system, and the central application subscribes or
> otherwise consumes information from the messaging middleware. Without some
> sort of verifiable sender identity attached to the message itself, the
> identity of the sender and the integrity of the message is assumed based on
> the integrity of all middleware involved in passing messages. If we include
> the sender's DNS name in the message and protect it with a signature, then
> it may be verified by the central application, independent of the transport
> over which it arrives. Then, mobile data network authentication becomes
> more about protecting availability and performance than preventing
> impersonation in a message-oriented application. Use cases centering around
> mobile network identities are a little more nuanced, and the available
> mechanisms can vary based on the mobile operator's tech stack. That's
> probably a better conversation for 3GPP.
>
> Consider that if a messaging middleware platform is trusted by multiple
> sophisticated smart cities applications, and none of those applications
> implement message authentication, the messaging middleware platform itself
> becomes an attractive target for a well-resourced adversary. Simply signing
> the messages passing through the system removes the pressure on the broker
> to ensure integrity, and reduces the value of a compromised broker.
>
> On Sun, Jun 13, 2021 at 3:22 PM Paul Wouters <[email-masked]> wrote:
>
>> Same here. I did give feedback in the past already but especially the
>> “client verification with and without dnssec” seem to be two widely
>> different problems. And the one without dnssec (webpki) already exists ?
>>
>> I have given this some thought in the last few weeks and I haven’t been
>> able to find a use case where one actually wants client authentication
>> using some IoT device on mobile data network. All use cases I can think of
>> would not want to expose the client via public dnssec key registry or via
>> public CA certs. I’d love to hear an example practical use case for DANISH.
>>
>> Paul
>> --
>> Danish mailing list
>> [email-masked]

--

---

From: Ash Wilson <[email-masked]>
Date: Mon, 14 Jun 2021 14:26:50 -0700

> explicitly in the charter, and then say why this work should not be in

This charter proposes the creation of an easier adoption path for DNS-based
identities, which includes DNSSEC. I don't think anyone here wants to sink
DNSSEC.

--

---

From: Ash Wilson <[email-masked]>
Date: Mon, 14 Jun 2021 15:24:04 -0700

Failed to reply to all earlier- here's the message back in-channel.

On Mon, Jun 14, 2021 at 10:53 AM Ash Wilson <[email-masked]> wrote:

> Hi Mike,
> Thanks for the feedback, responses in-line below...
>
> On Sat, Jun 12, 2021 at 9:56 AM Michael Richardson <[email-masked]>
> wrote:
>
>>
> In conversation with folks outside this group, but related to the topic at
> hand, the general perception is that the benefits of DNSSEC implementation
> do not outweigh the risk-related drawbacks. A few specific drawbacks cited
> have been: an anticipated increase in time to resolve DNS-related issues
> (uptime impact), a need for specialized knowledge in order to troubleshoot
> DNSSEC-related issues (hiring, training, retention), interoperability
> concerns with DNS-based load balancing and CDNs, and a general desire to
> avoid adding complexity that doesn't tie to some sort of competitive
> advantage for the business. This is anecdotal, and only represents the
> conversations I've had in trying to understand the feasibility of creating
> the protocol. A proper survey, perhaps conducted by registrars, would be
> quite useful for understanding and addressing the challenges that are
> impeding DNSSEC adoption.
>
>
>>
>>
> DNSSEC is important. I think that the benefits just aren't overshadowing
> the perceived risks. If DNSSEC is a requirement to even try a DNS-based
> device identity strategy, R&D groups may just seek a path of less
> resistance. Even if an R&D group purchases a separate domain for testing
> with DNSSEC, they still have to sell the idea to the organization's
> technical leadership before it can be adopted under the organizational
> domain. Depending on the organization, that can be a big gamble. The R&D
> group has little room to negotiate the topic of DNS-based device identity
> with technical leadership, without a transitional mode.
>
> If we have a transitional protocol mode which allows gradual adoption,
> enterprises can more easily demonstrate initial success with DNS-based
> identities. The full set of benefits, like direct support in the TLS
> protocol, can only be realized by completing the transition to DNSSEC. It's
> much easier to justify the adoption of DNSSEC if it's tied to increasing
> the success of an existing initiative. We certainly don't want to diminish
> the importance of DNSSEC- this is about incentivizing implementation by
> making it a part of an adoption path for DNS-based identities.
>
>
> Each device needing to be onboarded to an organizational PKI takes a
> certain amount of time to establish an identity within that PKI. With a
> large-scale deployment with many thousands of devices, the provisioning
> process can be time consuming and impacts the cost of the project. If a
> supplier ships devices with immediately useful DNS-based identities, then
> the network and application onboarding time can be reduced, which has a
> favorable impact on project cost.
>
>
> Good point. I was trying to keep it concise, but left out some detail
> where it could have been helpful.
>
>> --

--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Jun 2021 20:01:10 -0400

On Mon, Jun 14, 2021 at 02:26:50PM -0700, Ash Wilson wrote:

> This charter proposes the creation of an easier adoption path for
> DNS-based identities, which includes DNSSEC. I don't think anyone here
> wants to sink DNSSEC.

Well, but it sends a needlessly discouraging message, many of the
purported difficulties with signing authoritative DNSSEC zones are
anecdotal and outdated.  Yes, not all registrars support DNSSEC equally
well, but there are many registrars to choose from, vote with your feet
and $$.  Almost 15.2 million domains are already signed, the time has
come to stop working around the right way to securely publish data in
DNS.

Piling on work-arounds does in fact hinder DNSSEC adoption, and we
should seriously consider putting an end to this.

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Jun 2021 20:11:00 -0400

On Mon, Jun 14, 2021 at 02:13:10PM -0700, Ash Wilson wrote:

> over which it arrives.

The encapsulation is then basically CMS I guess.  Which supports
attaching a signature and the signer's certificate chain to a message
(as well as encrypting the message to the recipient(s)).

> Consider that if a messaging middleware platform is trusted by
> multiple sophisticated smart cities applications, and none of those
> applications implement message authentication, the messaging
> middleware platform itself becomes an attractive target for a
> well-resourced adversary. Simply signing the messages passing through
> the system removes the pressure on the broker to ensure integrity, and
> reduces the value of a compromised broker.

And I guess the proposal on the table is to use DNS as the identity
database for clients, with TLSA records enabling the use of enterprise,
or vendor CAs client onboarding.

If the verifiers are then infrastructure services, they're more than
capable of running a validating resolver, and sites sophisticated enough
to operate a private CA are more than capable of signing their doain.

Working around DNSSEC in this design seems rather more complex than
just using it.

-- 
    Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 14 Jun 2021 20:59:45 -0400

> should seriously consider putting an end to this.

The BoF proponents have no desire to sink DNSSEC. It's the opposite
in fact, but we also want to provide interim mechanisms for environments
that don't have DNSSEC yet.

I can also say from personal experience that deploying DNSSEC in
a large complex enterprise remains extremely challenging. Some of the
largest commercial DNS providers in the world have had constant
challenges handling the scale of my employer's signed DNS (ask me
offline sometime and I'll spill the beans). And just a few weeks ago, I
found another critical DNSSEC bug in one of the major open source
DNS implementations.

Shumon.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Jun 2021 21:29:18 -0400

On Mon, Jun 14, 2021 at 01:33:56PM -0700, Ash Wilson wrote:

> The objections I've encountered to DNSSEC (in having conversations
> with would-be implementers) relate generally to a perception that the
> benefits do not outweigh the risks.

Without some concrete justification for these perceptions, one might
treat them as mere superstition.  There are many wrong and outdated
memes out there, and some of them are worth dispelling.  We can document
best practices, substantial improvements in softwaree stacks that make
ongoing signing largely effortless, ...

> Some of those risks are related to technology challenges, and some
> relate to hiring the right skillset to maintain and troubleshoot a
> DNSSEC-protected domain.

But instead of crippling the next generation of technology, it may
well make more sense to address those issues (and they are in any
case getting actively addressed).

> In changing the location of DNSSEC in the adoption path for DNS-based
> identities, we allow organizations to experience some success and
> build confidence in the DNS-based identity strategy, which will
> further incentivize the eventual adoption of DNSSEC.

But the resulting protocol starts to look like a chimera.  Let's first
design a clean protocol, and then see whether there's a need to remove
actual barriers to adoption.

> hashes to support TLS server authentication' remedy the lack of clarity?

No, the actual problem is with this whole of "discovering" something.
What exactly are you looking to discover.  Perhaps you mean to say that
you want locate trust-anchors (possibly just EE key bindings) for a
given idenity.  That'd much less hand-wavy than "discovering
authenticated keys".

> signatures,

My problem is the phrase "key discovery", I don't know of any well
understood mean for that phrase.

> which does not rely on DNSSEC, may be experimented with and adopted by
> any domain.

I'd like to see the use-cases clearly stated, before jumping to "does
not rely on DNSSEC".

> If DNSSEC is a requirement for the message security use case (public
> key discovery for signature validation), then only 2.47% of all .com
> domains may even experiment with it.

That's not true at all.  Only the domains that want to do this need to
get signed, and there's nobody standing in their way.

> Justifying a transition to DNSSEC for an organization can be an uphill
> battle. If DNSSEC is a requirement for further exploration of a
> strategy that's already shown success, the chance of eventual adoption
> of DNSSEC will be greater.

Or, more likely, we'll enshrine yet another ugly work-around that'll be
with us for decades to come.

> > 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".
> 
> Detail was intentionally left out of this part.

Nevertheless, we can't just pepper the charter with meaningless
phrases, if it is going to be stated, it should be sufficiently
well defined to be understable.

> information to the application, then the information is not trustworthy.

You're misusing the term "uniqueness".  It seems you're looking for
something akin to name constraints that limit which CAs are authorised
to bind keys to names in a particular namespace.  That's not
"uniqueness".   Rather it is name-constrained federation, where each
part of the namespace is delegated to a select set of trust anchors.

The charter suffers from a very non-standard fuzzy vocabulary, and needs
more attention to either widely understood, and/or clearly explained
definitions.

> In a broader context, machines are being trusted not only to collect
> information and perform actions, but increasingly to decide when
> certain actions are to be performed. A more concrete example might be
> a system which manages the addition of chemicals (fluoride, etc) to a
> city's water supply, in response to telemetry from sensors. If a
> sensor can be impersonated via naming collision (intentionally or
> otherwise),

Your use of "naming collisions" is non-standard.  Collisions have
nothing to do with it.  The problem is who's trusted, not whether
the same name appears in more than one certificate.

> > An agreement on one namespace is essential for preventing naming

This looks misguided, again, it isn't about collisions.

> > > 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 is trying to

This needs better language in the charter.

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

You keep using that phrase, ... but it does not carry your intended
meaning.

> Ambiguity here refers to naming collisions possible when using
> multiple PKI within the same application.  What do you think about
> using "naming collision-free authentication across CAs" instead?

I want to see a charter which does not mention the word "collision",
which is not at all what you have in mind.

> > automate publishing data in DNS (signed or not), monitoring, ...

Then expect serious pushback, because zone signing is a solved problem,
the more difficult challenge is validation in captive portals, ..., but
that seems to be a rather marginal concern in the intended use-cases.

> in-message transmission of certificates and chains impractical or

Then they can mediate their communications through a proxy that
augments the signed message with the missing certificates.  Also
with DANE-EE(3) only the leaf certificate needs to be provided,
and it can be basically just the public key and a self-signature,
or even an RFC7250 raw public key.

> DNS name, and a signature.

> The authenticating central application can then

Or just use DANE-EE(3) and there's no need for any "certificate
discovery".  But if sending only the signature and not even the
EE cert is desired, a TLSA "3 1 0" record can provide the bare
public key, and you're done.  Presto magic, not certificates at
all to discover.

> demonstrate value in an identity strategy that eventually requires DNSSEC.

I am increasingly coming aroung to the view that this meme is outdated
and no longer justifiable.  There's no "eventually".

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Jun 2021 21:34:30 -0400

> found another critical DNSSEC bug in one of the major open source

For new applications one need not sign an existing legacy domain,
it is easy to register a new dedicated domain that's signed from
the getgo.

There may be some minor obstacles along the way, but it rather looks
like the software stacks are or will soon be ready to meet them head on.

The specs produced by DANISH will not change the world overnight, the
design should not be anchored in the past.

-- 
    Viktor.

---

From: Jacques Latour <[email-masked]>
Date: Tue, 15 Jun 2021 13:56:09 +0000

> The specs produced by DANISH will not change the world overnight, the design
> should not be anchored in the past.

I agree that anchoring in the past might not be the best path forward.  If one has to write code to support the past, might as well support future / DNSSEC...

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2021 13:21:54 -0400

> it is easy to register a new dedicated domain that's signed from

I was going to say the same thing.
It also has the advantage of not having to deal with the marketing department.

{However, it's a shame that example.com can't register devices.example.com
directly.... or rather that DNSSEC can't jump over the insecured
example.com.}
So one winds up with devices-example.com or some such situation.

    > design should not be anchored in the past.

We are in agreement here:  that's why I removed the mitigation as a work item
from the initial charter.  I think that we should still think about it though.

---

From: Ash Wilson <[email-masked]>
Date: Tue, 15 Jun 2021 10:26:31 -0700

Viktor,

Bringing it back first to what we agree on:

DNSSEC adoption has historically suffered from technical and perception
challenges. Many of those technical challenges have been resolved, but
still remain on the forefront of the would-be adopter's mind when
considering the adoption of DNSSEC. The IETF does a great job of
prioritizing the investment of time and effort in getting these issues
resolved and documented.

The current adoption of DNSSEC is disappointing. That number is currently
2.47% for the .com TLD (citing this time: http://rick.eng.br/dnssecstat/)

Not all CS college programs include DNSSEC (or PKI, for that matter) at
sufficient depth. Graduates aren't prepared to champion DNSSEC
implementation in the face of DNSSEC's perception problems in the
enterprise.

Now, some things we may not agree on:

Self-directed learning (in lieu of sufficient academic instruction) is
usually driven by some sort of curiosity, and encouraged by the
availability of the right materials.

For DNSSEC, the right materials exist. DNSSEC is one of the best-documented
sets of standards on the Internet. How-to guides are abundant. Nobody can
say that DNSSEC isn't well-documented.

Organizations with large DNSSEC footprints stand to benefit greatly from
DNSSEC adoption. Compared with configuring DNSSEC on a new domain, which is
a very simple and straightforward process, large organizations can face a
level of complexity that cannot be effectively automated.

It is easier to justify the adoption of DNSSEC as a part of a broader
initiative that adds some business value beyond improving the security of
an existing use case.

Within an organization which has not already adopted DNSSEC, it is easier
to justify initial exploration into a design pattern if DNSSEC is not in
the initial set of requirements. This makes the assumption that exploration
happens with oversight of enterprise technical leadership.

It is easier to justify the adoption of DNSSEC to business leadership if it
increases the value of an existing initiative, which is already showing
success. The risk/return balance then has some demonstrated benefit, which
makes a stronger argument against perceived risk.

If DNSSEC is in the initial set of requirements for DNS-based IoT device
identity, the desire to experiment with DNS-based device identity faces an
increased likelihood of rejection when compared to an adoption path where
DNSSEC is an eventual, rather than an initial, requirement.

Offering a transitional mode will make DNSSEC easier to justify, because it
brings more value to an initiative that can already show some limited
success.

Within an application where DANE TLSA records are already being used for
verifying message signatures, the ability to perform mutual TLS
authentication using TLSA records becomes a compelling argument in favor
implementing DNSSEC, even for an organization which has historically been
resistant to DNSSEC. I am proposing the use of DANE in TLS client
authentication as the gating factor for requiring DNSSEC.

Offering a transitional mode will positively affect the overall adoption of
DNSSEC. To what degree is up for debate, but I think that we can both agree
that some positive effect on the overall adoption of DNSSEC will result
from having a transitional mode. Where you and I seem to disagree is
whether the complexity involved is worth it.

--

---

From: Ash Wilson <[email-masked]>
Date: Tue, 15 Jun 2021 10:45:13 -0700

> So one winds up with devices-example.com or some such situation.

Purchasing a new domain for work use, when you work within a large company,
isn't always quick or easy. Sometimes you have an existing delegation to
work with (labs.example) and if DNSSEC is not a requirement for
exploration, you don't need to go through justification and procurement
before getting started.

--

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Jun 2021 15:14:06 -0400 (EDT)

On Mon, 14 Jun 2021, Ash Wilson wrote:

> Very often, mobile data used for IoT ends up going into a message broker or message queueing system, and the central application subscribes or otherwise
> consumes information from the messaging middleware. Without some sort of verifiable sender identity attached to the message itself, the identity of the
> sender and the integrity of the message is assumed based on the integrity of all middleware involved in passing messages. If we include the sender's DNS
> name in the message and protect it with a signature, then it may be verified by the central application, independent of the transport over which it
> arrives. Then, mobile data network authentication becomes more about protecting availability and performance than preventing impersonation in a
> message-oriented application. Use cases centering around mobile network identities are a little more nuanced, and the available mechanisms can vary based
> on the mobile operator's tech stack. That's probably a better conversation for 3GPP.

But the price of this method is revealing the DNS FQDN and IP of the IoT
device. I can't come up with a use case where an IoT device would gain
more than it loses from announcing to the world who it is and where it is.

Traditionally, this is all done using public/private CA's where the
client conveys it identity securely via TLS client authentication
using a certificate, or by not authenticating the TLS client and
forcint the client to do an authentication after the TLS connection
has estbalishes, eg via Basic Auth at the HTTP level.

> Consider that if a messaging middleware platform is trusted by multiple sophisticated smart cities applications, and none of those applications implement
> message authentication, the messaging middleware platform itself becomes an attractive target for a well-resourced adversary. Simply signing the messages
> passing through the system removes the pressure on the broker to ensure integrity, and reduces the value of a compromised broker.

But again, at a price of exposing the identity and the IP address /
locatin of the client. That makes it vulnerable to DoS attacks, eg
flood pings to its IP, or more subtle timing attacks - eg I ping it but
depending on the response time I can infer it is busy or not with its
actual job.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Jun 2021 15:45:45 -0400 (EDT)

On Tue, 15 Jun 2021, Ash Wilson wrote:

> It is easier to justify the adoption of DNSSEC as a part of a broader initiative that adds some business value beyond improving the security of an
> existing use case.
>
> Within an organization which has not already adopted DNSSEC, it is easier to justify initial exploration into a design pattern if DNSSEC is not in the
> initial set of requirements. This makes the assumption that exploration happens with oversight of enterprise technical leadership.
> 
> It is easier to justify the adoption of DNSSEC to business leadership if it increases the value of an existing initiative, which is already showing
> success. The risk/return balance then has some demonstrated benefit, which makes a stronger argument against perceived risk.

These arguments all applied to PKIX as well. Getting SSL on your server
was "too hard" and "too cumbersum" and traction was really low to
improve that, despite the strong case for it giving additional security.

Then ACME and LetsEncrypt came and automation solved this problem.

If DNSSEC is too difficult to do inhouse now, let your DNS hoster do it.
Route 53 supports it via a checkbox. Cloudflare supports it via a
checkbox. One click, done. Keep using the same TLS REST API to submit
DNS updates. It just gets signed.

Maybe some opensource tools need improving, eg lets get octodns to
support DNSSEC fully. Let's improve knot/bind's methods for "editing"
a zone so it works with DNSSEC.

> If DNSSEC is in the initial set of requirements for DNS-based IoT device identity, the desire to experiment with DNS-based device identity faces an
> increased likelihood of rejection when compared to an adoption path where DNSSEC is an eventual, rather than an initial, requirement.

I would really prefer the IETF does not engage with putting security
aspects in DNS records that are spoofable, and depend on a pluggable
non-DNS security stack for validation of these insecure records.

> Offering a transitional mode will make DNSSEC easier to justify

The transition mode will never transition further towards DNSSEC. And
as pointed out in this thread, that would be harmfull to DNSSEC
deployment, not helping transition to it.

> but I think that we can both agree that some positive effect on the overall adoption of DNSSEC will result from having a transitional mode.

I don't think so.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2021 15:48:59 -0400

> more than it loses from announcing to the world who it is and where it is.

Any communication from location FOO to MQTT server BAR, announces the device
to anyone that can see the traffic.

TLS1.3 does not send certificates in the clear, so neither would it send
TLS Client IDs to get the certificate in the clear.

By making TLS client side certificate authentication easier to manager, we
eliminate (default!) passwords in the device.

---

From: Ash Wilson <[email-masked]>
Date: Tue, 15 Jun 2021 12:53:42 -0700

Hi Paul,
Thanks for the feedback, responses/clarification in-line below.

On Tue, Jun 15, 2021 at 12:14 PM Paul Wouters <[email-masked]> wrote:

> otherwise
> > consumes information from the messaging middleware. Without some sort of
> verifiable sender identity attached to the message itself, the identity of
> the
> > sender and the integrity of the message is assumed based on the
> integrity of all middleware involved in passing messages. If we include the
> sender's DNS
> > name in the message and protect it with a signature, then it may be
> verified by the central application, independent of the transport over
> which it
> > arrives. Then, mobile data network authentication becomes more about
> protecting availability and performance than preventing impersonation in a
> > message-oriented application. Use cases centering around mobile network
> identities are a little more nuanced, and the available mechanisms can vary
> based

 The use case where messaging middleware is used to get the message from
the device to the service prevents the establishment of a TLS connection
directly between the producer and consumer of the information. In many
cases, the producer of the information doesn't even have IP connectivity.
The producer (mobile UE, pick your term) sends messages through the
provider network which eventually is presented for consumption by the
provider. A number of message-passing layers may still exist between the
mobile provider and the actual consumer of the messages produced by the
device.  The device has no IP to reveal, and the DNS FQDN is the sender's
identity. .

Some concept of sender identity is required for authentication and
authorization. The application shouldn't trust information that cannot be
attributed. If DNS is used as the public key discovery mechanism, the
authenticity of the payload and the identity of the sender can be verified
by the consuming application, even in the absence of a direct TLS
connection, and for senders which do not even have IP connectivity.

> has estbalishes, eg via Basic Auth at the HTTP level.
Correct, for environments where a direct connection between the device and
the core application are possible. Message brokers and other middleware
layers prevent the establishment of a direct TLS connection between
producer and consumer. Without a method for determining message sender
identity, authn/authz from the perspective of the consumer is assumed based
on the assumed integrity of every hop between the producer and consumer.

> implement
> > message authentication, the messaging middleware platform itself becomes
> an attractive target for a well-resourced adversary. Simply signing the
> messages
> > passing through the system removes the pressure on the broker to ensure
> integrity, and reduces the value of a compromised broker.
>

--

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jun 2021 16:43:29 -0400

On Tue, Jun 15, 2021 at 10:26:31AM -0700, Ash Wilson wrote:

> DNSSEC adoption has historically suffered from technical and perception challenges.
                      ------------                             ----------

The technical issues are solvable, and much progress has been made and
continues.  It is time to move beyond the historical misperceptions.

> 2.47% for the .com TLD (citing this time: http://rick.eng.br/dnssecstat/)

This is misleading.  What's more interesting is the marginal rate of
adoption of new domain registrations.  Recent measurements show this
to be around 20%!  We can make this even more appealing by actually
using DNSSEC in our standards.

> implementation in the face of DNSSEC's perception problems in the

Or DNS at all, or networking, ... people learn on the job.

> say that DNSSEC isn't well-documented.

I can definitely say that, because best-practices are not as well
understood as they should be, and the tools have improved dramatically
recently, so some relearning is required, and the tutorials have not
yet caught up.

There's work to be done, but none of if significantly insurmountable.

-- 
    Viktor.

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 21 Jun 2021 20:34:36 +0000

Hi Michael!

Thanks for this text.

Jumping in on this early message in the thread to comment on this slimmed down version of https://mailarchive.ietf.org/arch/msg/danish/03tYSTrnLVoeDy7KEd_HSUvVgPA/

> -----Original Message-----
> From: Danish <[email-masked]> On Behalf Of Michael Richardson
> Sent: Sunday, June 13, 2021 7:53 PM
> To: [email-masked]
> Subject: Re: [Danish] Proposed WG Charter
> 
> 

Concur with https://mailarchive.ietf.org/arch/msg/danish/xthh4QX4cfpodk1ftq3KnOmWhGI/ to use “object security” language (instead of message security).  Also recommend making it clear that this is generic approach not tied to a specific protocol (and if there are any limited dependences on message semantics such as "message contains the sender's DNS name" per slide #52 of https://datatracker.ietf.org/meeting/110/materials/slides-110-danish-danish-bof-slides-02, consider enumerating them to reduce scope and improve specificity if this list is short).

Is “identities” in this context more than a key or certificate?  It would be useful to down-scope/define identities somewhere.

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

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

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

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

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

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

> -Scope of work

I'm not recommending adding it in as it's additional scope, but EAP-TLS was mentioned:

https://mailarchive.ietf.org/arch/msg/danish/1K6Ht6C2KyrwRTj4Ii3rQE7ejCc/

and

https://mailarchive.ietf.org/arch/msg/danish/MUKQHXKXIAEEsnLRnIUJn95fZl0/

and also in the BoF slides.

That can be future work (that can be discussed in a future recharter of a WG)

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

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

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

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

> DANISH architecture document

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.

> DANE for client certificates (current draft)

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

> DANE for TLS client authentication (current draft)

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?

Regards,
Roman

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Jun 2021 17:08:30 -0400

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.

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

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

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

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

okay.

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

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

Thank you, that's very useful.

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

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Jun 2021 22:00:18 -0400

So, the initial charter from June 12 is now at:

  https://github.com/mcr/danish-bof/commit/6c9a50804d086679c06172f085915b9dad7970db

My proposed revised charter is at:
  https://github.com/mcr/danish-bof/pull/1/files?short_path=d22b3d6#diff-d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97

In all it's github annotated Markdown glory!

These are my edits this evening based upon Roman's comments earlier today.

  https://github.com/mcr/danish-bof/pull/2/files?short_path=d22b3d6#diff-d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97

I would appreciate github level comments on the comments, particularly from
Roman.

---

From: Jacques Latour <[email-masked]>
Date: Thu, 24 Jun 2021 20:07:40 +0000

Hi,

"In response to the challenges related to ambiguity between client 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 wishing to turn lights off to reduce room temperatures can not authenticate to the lighting control system.

This does not resonate with me yet " This creates a silo effect where different parts of large deployment can not communicate. " I think the problem is that each silo cannot authenticate each other in trusted manner,  if IoT device company A knows it's allow turn the light switch on IoT device company B when the sun sets, then there's no mechanism today to authenticate themselves with a unique identity?...   and there needs to be a control system somewhere that says IoT device A can control IoT device B, that controls system today also need to authenticate the IoT devices....

It's clearer in my head than on the email... ☹

Jack

> Sent: June 21, 2021 10:00 PM

> To: Roman Danyliw <[email-masked]>; [email-masked]

>   https://github.com/mcr/danish-<https://github.com/mcr/danish-bof/commit/6c9a50804d086679c06172f085915b9dad7970db>

> bof/commit/6c9a50804d086679c06172f085915b9dad7970db<https://github.com/mcr/danish-bof/commit/6c9a50804d086679c06172f085915b9dad7970db>

>   https://github.com/mcr/danish-bof/pull/1/files?short_path=d22b3d6#diff-<https://github.com/mcr/danish-bof/pull/1/files?short_path=d22b3d6#diff-d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97>

> d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97<https://github.com/mcr/danish-bof/pull/1/files?short_path=d22b3d6#diff-d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97>

>   https://github.com/mcr/danish-bof/pull/2/files?short_path=d22b3d6#diff-<https://github.com/mcr/danish-bof/pull/2/files?short_path=d22b3d6#diff-d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97>

> d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97<https://github.com/mcr/danish-bof/pull/2/files?short_path=d22b3d6#diff-d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97>

> Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )

CLASSIFICATION:CONFIDENTIAL