On Thu, Aug 15, 2024 at 3:16 AM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Wed, Aug 14, 2024 at 07:13:57PM -0400, Phillip Hallam-Baker wrote:
> The certificate entries were removed when the draft moved into PKIX
> becoming CAA so as not to conflict with DANE. But the DANE group did not
> take note of the differences between the drafts and insisted on an approach
> that the Chrome group had rejected.
>
> I am not sure if I can fully remember the subtleties of the issues and
> which were mine and which were the Chrome teams. But the big issue for
> Chrome was always speed of resolution because THEIR ANNUAL BONUSES DEPENDED
> ON IT. So the CAA scheme was very carefully constructed so that it would
> not increase the resolution time. Another major difference is that DANE is
> certificate publication where CAA was certificate authentication. Finally,
> CAA does not require DNSSEC while DANE joined itself to at the hip.
You're comparing apples and oranges, the audience for CAA is a candidate
issuer CA, not the relying party as with TLSA. CAA is not relevant
during TLS connection setup.
So sure, CAA does not impact resolution time because browsers simply
never use it.
The original spec did, that is the point. And that spec had buy-in from the Chrome team.
But instead of following that approach, the DANE group ignored it and made plain that contributions from either of the authors was unwelcome. Then complained that they were not getting deployment.
The problem was that certain people made destroying the CA industry their primary goal and cut themselves off from the expertise relevant to the problem they claimed to be solving. My goal was to build a market for selling DNSSEC services through the DNS registrars which were the main channel for selling certificates. The registrars sold DNS names as loss leaders and made their money on SSL certs. So instead of driving DNSSEC deployment, DANE actually sabotaged it.
