Re: [Acme] CAA DNS RR IODEF e-mail spam && client side CAA verification

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 06 November 2020 16:47 UTC

MIME-Version: 1.0
References: <fd15218159ce22d9f3f846de1b5bac498fb6116b.camel@sijanec.eu> <CAErg=HGibOhM3Ab58VrspoN=pgxTi8fHy6n+9R3izUda+29w1w@mail.gmail.com>
In-Reply-To: <CAErg=HGibOhM3Ab58VrspoN=pgxTi8fHy6n+9R3izUda+29w1w@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 06 Nov 2020 11:46:51 -0500
Message-ID: <CAMm+LwiOz33PUO_vMxEkM_-3Tcq4ok4iD5qn6VmpA-ySZ0Pyjw@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: Anton Luka Šijanec <anton@sijanec.eu>, acme@ietf.org
Content-Type: multipart/alternative; boundary="00000000000033fae105b372f61c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/HHTMJHNYmlKOdnTcGz6Xr6KhEuA>
Subject: Re: [Acme] CAA DNS RR IODEF e-mail spam && client side CAA verification
Precedence: list

On Thu, Oct 22, 2020 at 1:05 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

>
>
> On Thu, Oct 22, 2020 at 11:59 AM Anton Luka Šijanec <anton@sijanec.eu>
> wrote:
>
>> Hello!
>>
>>
...

> If such a system is already in place, how can I make sure I am
>> correctly implementing it on my domain? Can someone direct me to the
>> specification?
>>
>> My second suggestion is that client browsers would verify certificates
>> by performing DNS CAA queries and validating if the certificate is okay
>> and optionally send violation reports. What are your thoughts?
>
>
> This is intentionally, and explicitly, not part of CAA. CAA is designed as
> an ACL on issuance; were clients to check, this would necessitate that
> domains continue to authorize future certificate issuance.
>
> For example, if I used CA A at Time 0, but later switched new issuance to
> CA B at Time 10, if clients checked at Time 11, I would be required to list
> both A and B as authorized; A, because it had authorized some of my
> existing certificates, and B, because it was authorized for new
> certificates.
>
> Short of replacing every unexpired, unrevoked certificate from A, I would
> not be able to safely and securely only authorize B going forward.
>
> Section 1 of RFC 8659 makes this unambiguous:
> > Relying Parties MUST NOT use CAA records as part of certificate
> validation.
>

All correct.

But when I originally proposed CAA, we did not have Certificate
Transparency. Nor was DNSSEC deployed. Also, the very first draft of CAA
was joint with Ben Laurie and we were proposing using CAA as a means of
publishing data of that sort.

If the application warranted it, you could establish a check of CAA by
pickling the DNSSEC validation chain in the CT logs (we did consider a cert
extension).
The problem with trying anything of that sort is that PKIX is now patches
on patches on patches and this is a lot of complexity for not very much
advantage.

The WebPKI was originally designed as an authentication and accountability
infrastructure to enable online commerce. It is used for much more but many
of the constraints imposed by that original application make it a really
poor choice for a lot of applications even if Lets Encrypt is giving free
certs.

WebPKI certs are bound to DNS names. WebPKI certs have a fixed expiry.
Neither of those properties is appropriate for the purpose of establishing
a secure conversation with my WiFi router, my coffee pot, etc. etc.

Another limitation on WebPKI is that it is built using 1980s public key
cryptography and the state of the art in crypto is now threshold.

Re: [Acme] CAA DNS RR IODEF e-mail spam && client… Ryan Sleevi
Re: [Acme] CAA DNS RR IODEF e-mail spam && client… Phillip Hallam-Baker