[dns-operations] DNSSEC deployment incentives

[Phillip Hallam-Baker]

On Wed, Jun 19, 2019 at 1:18 PM Paul Vixie <paul at redbarn.org> wrote:

>
>
> Phillip Hallam-Baker wrote on 2019-06-19 09:54:
> >
> >
> > On Wed, Jun 19, 2019 at 11:43 AM Paul Vixie <paul at redbarn.org
> > ...
> >      > > But Let's Encrypt de-monetized certificate issuance, so now that
> >      > > obstacle is moot.
> >      >
> >      > It has also eliminated the incentive to deploy DANE for free
> certs.
> >
> >     not for me, but i think you may be right in general.
> >
> >
> > That depends on whether your objective here is to deploy DANE TLSA
> > records or solve the problems they were originally intended to address.
>
> there wasn't a single "original intention". i had qualms about TLSA but
> i chose to live with it because it was close enough -- like most
> standards, there was a problem statement mismatch (against my own hopes
> and dreams). apparently there were hardliner elsewhere in the ecosystem
> who took a "my way or the highway" approach, and declined to deploy. i
> suggest holding one's nose to avoid the bad smell, as we must all do
> with dnssec itself.


My problem with it was the complete lack of though given to deployment
incentives. That is not something I see much point trying to retrofit.

> We have tried four separate end-to-end mail enhancement protocols over
> > the years, PEM, MOSS, OpenPGP, S/MIME. Why should we assume that if the
> > DANE WG couldn't deliver that nobody can?
>
> the DANE WG delivered something i can live with, that solves my own CA
> problem. no doubt there are others in the CA world or the TLS world who
> have larger or smaller problems than what DANE TLSA solves. i was not
> expecting any support from the CA industry which TLSA may disrupt, and
> perhaps there's enough overlap between the CA and WWW industries that
> they are making common cause here for reasons of simple solidarity. i'll
> never know. i do know that TLSA is working fine for e-mail, and i know
> of no defects so all-encompassing that they would prevent TLSA from
> working for HTTPS also. in short, i think you're encoding your
> perspective into your conclusion here.
>

TLSA has progressed in precisely the fashion I expected. So I don't think
my perspective is incorrect.

But the deeper issue is that it just isn't a problem I have a great deal of
interest in solving right now. Server authentication is a solved problem as
far as the Web is concerned. It is solved by the WebPKI built on PKIX, with
CAA and CT adornments. I can't see how the industry is going to move from
one hold your nose solution to another.

The problem I do not see as being solved is on the client side and that is
where I have been working for most of the past 5 years.


> The big problem with DANE is that they got the architecture wrong from
> > the start. The way to get security policy to work is to consider it as a
> > part of a comprehensive service discovery mechanism based on the SRV
> > mechanism which you invented and Stuart Cheshire et. al. extended with
> > the companion TXT records.
>
> that way would also work, though i note with dismay that the WWW
> industry has resisted all calls for SRV support, since day 1, and as a
> result, there's now great effort expended to standardize "ANAME", which
> would have been moot if the WWW community hadn't resisted "SRV". do we
> both see history repeating, and are we both sanguine about it?
>

ANAME is not necessarily the same as SRV but they could certainly have used
SRV instead.

If you recall, it was only the browser folk who resisted SRV. Back in the
early days, I was probably a much stronger proponent than you were. Though
it is always easier to promote someone else's work hard.



> > My proposal for doing this is here:
> >
> >
> https://tools.ietf.org/id/draft-hallambaker-web-service-discovery-01.html
> >
> > You will note that almost the entire spec is constrained by the previous
> > SRV and DNS Service discovery drafts. The only thing I introduce that is
> > new is a BASE32 mechanism for presenting fingerprints of security
> > policies, root certificates etc. etc.
> >
> > https://tools.ietf.org/html/draft-hallambaker-mesh-udf-02
> >
> > This approach provides a superset of DANE capabilities without the need
> > for any new records. It allows the security policy description to be
> > obtained with a minimal number of round trips and the mechanism can be
> > used for discovery of any service. Thus an authoritative DNS server can
> > provide all the information required for service connection in a single
> > round trip as additional RRs.
> >
> > DANE was a wasted opportunity because they started from the wrong place.
>
> i think it's misleading and unwise to speak of DANE in the past tense.
> at a glance, your proposals were better. but many proposed alternatives
> to DNSSEC were (and remain) better than DNSSEC, too. technical merit is
> not the decisive criteria here. in the ietf's rough consensus model, we
> stop arguing when everybody is equally unhappy and exhausted; not before.
>

That isn't my DANE alternative, it is my current proposal that I wrote to
support the Mesh. But it is a generalized service discovery mechanism that
happens to be capable of validating a trust root in passing rather than
being limited to trust root validation. So this is like the way that very
few people were organized enough to use the old style click pedometers to
count their number of steps every day but it is a trivial thing to do that
when it is one of the functions of your watch.

One of the pathologies of IETF is that problems are reduced to the smallest
possible scope so as to make the WG tractable but resulting in a proposal
that is just too limited to be interesting.


The other big difference is that I don't require a domain to be DNSSEC
signed for this purpose but I will (eventually) require clients to perform
the validation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190619/66ff6313/attachment-0001.html>