Re: [Danish] Proposed WG Charter

[Ash Wilson <[e-mail]>]

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.


On Mon, Jun 14, 2021 at 6:29 PM Viktor Dukhovni <[e-mail]>
wrote:

> 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.
>
> --
> Danish mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/danish
>


-- 

*Ash Wilson* | Technical Director
*e:* [e-mail]

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.