Re: [Danish] Proposed WG Charter

[Viktor Dukhovni <[e-mail]>]

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

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

> > 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?
> 
> Would replacing 'discovering authenticated keys' with 'discovering keys or
> 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".

> A DNS-based public key discovery mechanism for authenticating message
> 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.

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

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.

> > > The DNS namespace, together with DNSSEC, forms the most widely-recognized
> > > namespace and authenticated discovery mechanism on the Internet.
> >
> > Not clear what this is intended to convey.
> >
> > An agreement on one namespace is essential for preventing naming
> collisions.

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
> > evoke lack of effective name constraints in the WebPKI?
> 
> Yes, you are correct.

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.
> >
> > Again, what exactly is this tryign to get at?
> 
> Time is spent onboarding devices to the same PKI, to avoid naming
> collisions.

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

> > It seems that solving "ambiguity" is a major concern.  So the term needs
> > 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?

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

> > 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, ...
>
> DNSSEC zone signing

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.

> > 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?
> 
> IoT applications frequently have network constraints which make the
> in-message transmission of certificates and chains impractical or
> impossible.

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.

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

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.

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

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

-- 
    Viktor.