Re: CAA Certificate Problem Report

[Matthew Hardeman via dev-security-policy]

I concur in full with Nick Lamb's comments and positions on this matter.

There is no reasonable short cut to actually doing the DNSSEC thing if we want 
to usefully intertwine those technologies at all.

There IS significant benefit in enforcing complete DNSSEC validation for (all) 
the domain validation DNS queries where DNSSEC has been configured for the 
relevant zones.

This is especially the case for CAA records, which have an explicit security 
function: controlling, at a minimum, who may issue publicly trusted 
certificates for a given FQDN.

I will note that from the software development perspective, I concede that many 
of the DNS query APIs don't surface (at least in a friendly way) exactly what 
the nature of the DNSSEC validation failure is or at what layer of delegation 
the validation fails.

My position is that ultimately, that doesn't really matter:  If a CA wanted a 
quick and easy path to differentiating whether a domain has a DNSSEC problem or 
a CAA problem, chase the queries from the root down both with DNSSEC validation 
on and with DNSSEC validation off.  If no errors arise (because DNSSEC is not 
configured, etc) then rely on the CAA records alone.

If, however, a DNSSEC validated response comes back but errors exist on DNSSEC 
enabled queries for the CAA records, presume there's a DNSSEC problem of some 
sort and let the DNS / site admin work out the specific failure.  
Alternatively, do further digging for the mode of failure outside of the 
issuance path, in a separate after-adverse-decisioning debug / diagnostic path.

It is undeniable that DNSSEC validated query resolution takes longer than 
queries without DNSSEC.  Regardless, these are not terribly lengthy.  If the 
finding is that they are lengthy, reduce the local max timeout for whatever 
phases are taking too long.

I'm having trouble understanding how even several seconds of (asynchronous) 
delay can be a factor of great concern for a commercial CA.  I would assume 
that all kinds of checks are going on in parallel with callbacks hitting and 
the certificate advancing to signing when all the necessary callbacks have 
updated the test status to good.  I'm certain that one absolutely could build 
such a set of asynchronous work queues which would perform tests in a 
significantly parallel fashion for a great many pending certificates and then 
push each pending certificate to the actual signer in the moment that the last 
callback for a given required test posts GOOD on a particular pending issue.  
Let them process out-of-order prior to hitting the signer, submitting to the 
final FIFO signing queue in the instant that the last test which clears the 
issuance decisions transitions to positive.

I'd like to comment that DNSSEC and CAA in combination are, to my mind, the 
only presently available solution of an unambiguous nature for prevention of 
fraudulent domain-validation success results in a world where a significantly 
connected BGP participant might hijack ones IP space.  On this basis, I assert 
that there is real and distinct value in enforcing the sanctity of CAA or 
sanctity of lack of CAA via DNSSEC validation wherever DNSSEC has been 
configured.

Without managing to hoodwink the TLD registry or associated TLD registrar for a 
domain, there is no way for a successful IP space hijack to yield manipulated 
results to DNS queries answered by authoritatives in said hijacked IP space -- 
if and only if DNSSEC validation is performed.

I put forth that the security of the root zone delegation, and delegation from 
the TLD registrar/registry to the authoritative zone IS or CAN BE far more 
secure than DNS queries without cryptographic validation in a world where the 
IP space underpinning an authoritative DNS server can be (fairly) easily 
hijacked.

For what it's worth, I'd also LOVE to see an extension option to CAA records 
which standardize ways of indicating acceptable domain validation methodologies 
along with acceptable CAs.  For example, it would be nice to be able to say 
"Allow only Let's Encrypt to issue; Allow issuance only when domain validation 
mechanism relies exclusively upon DNS".  In this environment, even if someone 
hijacks the IP space of a web server within the domain, they are unable to get 
a certificate issued because they can't skip the CAA and the DNSSEC is keeping 
the issuance from occurring because it requires a DNS proof for issuance, 
rather than allowing the random-verification-content-in-a-well-known-url 
validation.

Just my thoughts on the matter...

Thanks,

Matt Hardeman
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Nick Lamb via dev-security-policy]

Gerv, rather than start by digging into the specific technical details, let me 
ask a high level question.

Suppose I have deployed DNSSEC for my domain tlrmx.org and I have a CAA record 
saying to only permit the non-existent Gotham Certificates gotham.example to 
issue.

You say you don't want CAs to need to implement DNSSEC. But you also don't want 
them issuing for my domain. How did you imagine this circle would be squared?

If a CA doesn't implement DNSSEC bad guys can send them a forged answer to any 
query and they'll believe it. We might say to ourselves "Oh, the CA should take 
reasonable precautions to prevent that" but er, the reasonable precaution is to 
implement DNSSEC.

The arguments against DNSSEC in ordinary clients end up being about 
practicality, it would be difficult and costly. Ok. But running a public CA is 
already difficult and costly. Trustworthiness is not cheap.

I've also seen a few complaints about DNSSEC being slow at scale. As I 
understand it Let's Encrypt used DNSSEC at scale from its inception.   Whether 
they're really "biggest" in some sense is debatable, but they're definitely not 
a boutique outfit, if they can do it then it's clearly not impossible.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

[Quirin Scheitle via dev-security-policy]

Hi,

just wanted to update that Certum has also issued on this domain: 
https://crt.sh/?id=209378608

I have opened a support ticket, which has led to revocation but not a qualified 
statement as to what happened yet. 

Kind regards
Quirin

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

[Dmitry Belyavsky via dev-security-policy]

Dear Nikos,

On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos 
wrote:

> On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky 
> wrote:
> > Hello,
> >
> > Here is the new version of the draft updated according to the discussion
> on
> > mozilla-dev-security list.
>
> Hi,
>  It seems that most of the details of the underlying format are
> missing. As far as I understand it is mostly an intentions document at
> this point right? I have few comments:
>

The format will be CRL-like.

>
> 1. requiredX509extensions: What's the reasoning behind this? If these
> extensions are required and not present why keep the root certificate
> in the trust store?
>

The main intended case is "require Certificate Transparency".
Currently using the CT is not mandatory for all CAs.


>
> 2. What is the difference between issuedNotAfter and trustNotAfter?
> The description text is unclear to me.
>

issuedNotAfter - we do not trust to the certificates issued after the date.
trustNotAfter - we do not trust certificates after the date XXX, if they
have notAfter > XXX


>
> 3. applicationNameConstraints: very useful, however it is unclear from
> the ASN.1 description how are these stored.
>

I'm not so familiar with ASN1 format. I think that syntax from RFC5280 will
fit here.

>
> 4. How do you handle extensions to this format?
>
> Simillary to CRL. Do you have ideas of the extensions?


> Overall, why not use X.509 extensions to store such additional
> constraints? We already (in the p11-kit trust store in Fedora/RHEL
> systems) use the notion of stapled extensions to limit certificates
> [0, 1] and seems quite a flexible approach. Have you considered that
> path?
>
> regards,
> Nikos
>
> [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/
> storing-trust-model.html
> [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-
> certificates.html
>

Thank you very much, I'll look at it.

-- 
SY, Dmitry Belyavsky
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

[Inigo Barreira via dev-security-policy]

Thanks Quirin, we´re working with Primekey to know what happened (we´ll
generate a report once known) and will contact you if necessary to check
that info you have.

Regarding the logs, the log message actually means that CAA either
explicitly permitted the issuance, or implicitly permitted issuance (e.g. by
the lack of a CAA record, that according to this email that´s no the case).
We´re also checking if the DNS resolver server was caching the timeout
failure and sent a SERVFAIL or similar response the second time, rather than
letting the query time out again. But, as said, we´re still investigating
the issue.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Quirin Scheitle via dev-security-policy
Sent: martes, 12 de septiembre de 2017 20:30
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

Hi all,

Thank you for the replies. I am glad that there is agreement these
certificates should not have been issued. 

I am confident that the test behaved correctly, the last edit on the zone
file was on Aug 31 17:24, and it reads:

crossbear.org.  0   CAA 0 issue ";" 

So even if requests would somehow have gotten through the iptables rule
dropping them, it would definitely not have gotten a permitting record. 

I also have full pcaps from both name servers serving this domain and can
confirm that not a single query response was sent to any server on September
8th  and 9th.

crossbear.net is a different domain with a different configuration, it is
unrelated to this issue.

Inigo, I am very happy to debug this in detail offline -- I have plenty of
records and data to assist debugging. 

Kind regards
Quirin
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy