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

Ryan Sleevi <ryan-ietf@sleevi.com> Thu, 22 October 2020 17:05 UTC

MIME-Version: 1.0
References: <fd15218159ce22d9f3f846de1b5bac498fb6116b.camel@sijanec.eu>
In-Reply-To: <fd15218159ce22d9f3f846de1b5bac498fb6116b.camel@sijanec.eu>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Thu, 22 Oct 2020 13:04:48 -0400
Message-ID: <CAErg=HGibOhM3Ab58VrspoN=pgxTi8fHy6n+9R3izUda+29w1w@mail.gmail.com>
To: Anton Luka Šijanec <anton@sijanec.eu>
Cc: acme@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ca9ebb05b24576ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/7Cm0RIyeDz2wZD4l3HzHT8jvZc8>
Subject: Re: [Acme] CAA DNS RR IODEF e-mail spam && client side CAA verification
Precedence: list

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

> Hello!
>
> I hope I am addressing this e-mail to the correct mailing list. After
> glancing through the CAA DNS RR specifications for allowing only
> specific CAs to issue certificates for a specific domain, I saw that
> the iodef field for specifying the URI for sending violations is not
> verified when submitting reports to different domains.
>
> What I mean by this is that someone.example can specify an email
> address of someone@else.example. Then someone.example issues a lot of
> certificate signing requests to CAs that are not allowed for his
> domain, filling someone@else.example's inbox with violation spam.
>
> I propose a system, such as the one used for DMARC, to allow
> whitelisted cross-domain violation email delivery.
>
> For example, if IODEF field of caa.example specifies "mailto:
> report@violation.example", CAs will before sending a report check if
> the TXT record caa.example._caa.violation.example. has a value of
> "CAA=v1; caa-reports=allow;" or something similar.
>
> 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.

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