Re: [saag] [lamps] subordinate vs intermediate certification authority

[Viktor Dukhovni <[e-mail]>]

On Mon, Feb 08, 2021 at 01:41:15PM -0500, Phillip Hallam-Baker wrote:

> > With DANE-TA(2), the server is *asserting* the trust-anchor that's
> > relevant for validation of its certificate.  It is not a pin as such.
> > The real trust-anchor is the DNSKEY RRset that ultimately signs the
> > chain leading to validated TLSA records.
> 
> Using DNS to anchor WebPKI certs is like trying to nail oak posts to jello.

[ Colourful aside ignored. ]

> All you have is a chain of trust up to the ICANN yacht club root of trust.
> You don't own a DNS name, you rent it. And companies that charge $250,000
> to apply to register a name have shown themselves to be untrustworthy.

At least I know who it chains to.

> > Clients that implement DANE-TA(2) support will use whatever appears in
> > the TLSA record, so there's no assumption of client policy.  (Indeed
> > less assumption of client policy than with WebPKI, where one must
> > tacitly assume that the CA one has elected to issue one's certs is
> > trusted by the relevant clients).
> 
> And ten years after DANE started, those widely deployed clients would be?

Postfix, Exim, Power-MTA, Halon MTA, Cisco ESA, Microsoft Azure hosted
Exchange (scheduled to go live this month), gmx.de, Protonmail, Postini,
mailbox.org, ...

Of ~14 million DNSSEC signed domains, 2.54 million have DANE TLSA RRs
for their MX hosts.

> > This is entirely a server-side issue: operational negligence,
> > unrelated to client policy.
> 
> No, it is a protocol failure. There are no incompetent users, only
> incompetent service providers. There are no incompetent
> administrators, only incompetent protocol architects.

I disagree, but the protocol failure, if you really insist on calling it
one, resulted from a compromise, where some folks wanted DANE to be
simple and just support DANE-EE(3), but some others wanted more
features, and so DANE has four certificate usages, of which only 2 are
suitable for SMTP, but almost everyone is wisely using DANE-EE(3).

Once I release "danebot" (in alpha now), which makes it easy to manage
DANE-EE(3) reliably with Let's Encrypt, more users will switch to
DANE-EE(3) and DANE-TA(2) should become increasingly rare.


> The sine qua non for all security policy is to automate the management
> of the services so that the policy advertisements are always up to
> date.

100% agreement, hence "danebot" coming to github soon.

> > Perhaps this is the short version of what I tried to spell out in more
> > detail.
> 
> DNSSEC is simply the WebPKI with a minimum of two trusted parties per path
> (ICANN + TLD registry). Oh and a heck of a lot more registries.

A system that eliminates redundant third parties in asserting domain
control.  The same ICANN root and registrars are also trusted parties
in DV cert issuance.

> If people want to pin keys to a name, the only way to do that in a
> practical way is to make the naming system and PKI co-extensive. That is
> not a feature that can be added to DNSSEC or to PKIX.

If the names are *DNS* names, then the parties that can delegate and
transfer control of domains are the natural parties to publish
assertions about trusted keys for those domains.

Some would redesign the domain hierarchy with various block-chain like
schemes, I don't expect these to succeed, but have no prior objections
to exploring other trust models.  Whatever the model, it should not
have redundant trusted 3rd-parties publishing assertions that the
principals can publish directly.

-- 
    Viktor.