Subject: [Uta] CAA DNS RRs (RFC6844), DNSSEC and MTA-STS

From: Aaron Zauner <[email-masked]>
Date: Sat, 18 Jun 2016 13:53:20 +0800

Hi,

RFC6844 defines a method by which domain owners can limit the CA allowed to issue certificates for their domain. As far as I can tell this isn't widely implemented in DNS Daemons (KnotDNS and Bind9 [urgh]) do have support though. Is this something that might make sense including in the MTA-STS document?

i.e. one could effectively restrict validation to a certain CA (say for example Let's Encrypt).

I'd apprechiate input on that one from implementers and operators. Is this used in practice? Does it work?

Thank you,
Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Jun 2016 05:59:27 +0000

On Sat, Jun 18, 2016 at 01:53:20PM +0800, Aaron Zauner wrote:

> RFC6844 defines a method by which domain owners can limit the CA allowed
> to issue certificates for their domain.

Critically, this signalling channel is *exclusively* between the
domain and any CA that might consider issuing a certificate for
the domain.  It MUST NOT be used by relying parties.

Unfortunately, the CA/B forum voted to make support for this
optional, so this standard is stillborn.

> As far as I can tell this isn't widely implemented in DNS Daemons (KnotDNS
> and Bind9 [urgh]) do have support though. Is this something that might
> make sense including in the MTA-STS document?

See above, CAA does not apply to relying parties, and has no
relevance to STS.

> i.e. one could effectively restrict validation to a certain CA (say for example Let's Encrypt).

One could attempt to ask other CAs to not issue certificate for
one's domain.  In practice, this is mostly useless.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 18 Jun 2016 14:35:28 +0800

> On 18 Jun 2016, at 13:59, Viktor Dukhovni <[email-masked]> wrote:
> 

Thank you for the information. I'm not very familiar with this standard nor it's history, so that's much appreciated.

> See above, CAA does not apply to relying parties, and has no

Yea, I *was* thinking it could be mentioned in the security considerations section as additional protection - if that makes sense.

So for example: various CDNs and DNS providers offer API's - in Certbot we could interface with them to make sure relevant CAA's are set and protected by e.g. DNSSEC. Just an idea.

> one's domain.  In practice, this is mostly useless.

How would that work? You mail each CA not to issue for your domain and expect that they'll honor your request (also intermediates)? I'm not sure where you're going with that. It doesn't seem like anything that would actually work in the real world and the threat model is just insane.

Thanks for the feedback!
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 18 Jun 2016 14:40:02 +0800

> On 18 Jun 2016, at 14:35, Aaron Zauner <[email-masked]> wrote:
> 
> 

That being said; an option to pin to the public key of a certain intermediate CA is far more useful, with the caveat of roll-over and broken/bouncing mail transfer.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Jun 2016 16:43:09 +1000

> On Jun 18, 2016, at 4:35 PM, Aaron Zauner <[email-masked]> wrote:
> 
>>> 

Sorry, I was a bit too concise, by "ask other CAs" I meant "publish a CAA"
RRset, and in my view this is pointless, because most CAs don't support the
optional CAA standard.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Jun 2016 16:59:43 +1000

> On Jun 18, 2016, at 4:40 PM, Aaron Zauner <[email-masked]> wrote:
> 

You're starting to invent DANE.  There are now 1181 DANE SMTP domains
with LE certificates in my survey...

[ The total count is 31451, but only 63 have appeared in Google's email
  transparency report (up from 25 last October). ]

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 18 Jun 2016 18:15:33 +0800

> On 18 Jun 2016, at 14:59, Viktor Dukhovni <[email-masked]> wrote:
> 
> 

I meant with MTA-STS. They do have public key pinning as a future work item already?

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Jun 2016 12:47:32 +0000

> I meant with MTA-STS. They do have public key pinning as a future work item already?

Key pinning is most unlikely to be practical with STS.  It is
probably best to not specify it, to keep the spec simple and to
reduce the chance of domains shooting themselves in the foot.

-- 
	Viktor.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 18 Jun 2016 07:16:19 -0700

> That being said; an option to pin to the public key of a certain intermediate CA is far more useful, with the caveat of roll-over and broken/bouncing mail transfer.

You are betting on your CA still using the same intermediate CA the next 
time it issues you a certificate. I wouldn't count on that.

Thanks,
	Yaron

---

From: Aaron Zauner <[email-masked]>
Date: Sun, 19 Jun 2016 17:51:46 +0800

> On 18 Jun 2016, at 22:16, Yaron Sheffer <[email-masked]> wrote:
> 
>> 
> You are betting on your CA still using the same intermediate CA the next time it issues you a certificate. I wouldn't count on that.

I'm not. Specifically that is one of the issues I meant to address by writing "with the caveat oif roll-over and broken/bouncing mail transfer".

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Sun, 19 Jun 2016 17:54:41 +0800

Aaron